Re: Separation of configuration and control - good or bad?

[Larry Menten <lmenten@lucent.com>]

David T. Perkins wrote:

> HI,
>
> In the below... I'm confused. Why would I need two parsers?
>  
I do not mean the SAX or DOM parser.  I mean the code that
is driven by the SAX events or traverses the DOM tree.

> Also, I'm concerned that it's starting to look like that
> if I have a device that has "config X", and I reboot the
> device and I want it to come back up in "config X", then
> there maybe a combinations of config and control operations
> that have to be applied.
>  
The control operations are for dealing with transient state,
such as neighbor adjacency, LSDB content, and the like.
A "reset" operation is a simple example.  These have no
effect on config state. They have an impact on the running
state of the system. 
A request for "graceful restart" to occur is an example of such a
request.

> One final comment... I believe that providing the capability 
> for authorization is another factor that is going to affect
> the look and feel of the protocol. 
>  
This is true and is another reason, IMO, that a representation that clearly
identifies the target and scope of the operation is important.  The Enns
proposal does not do so.  Looking at an Enns transaction, you cannot
verify that the user has the authorization to perform it.  You must examine
the current state of the target config to know what objects will be created
by the transaction.

> At 03:18 PM 5/15/2003 -0400, Larry Menten wrote:
>  
> > Andy,
> >
> > If control operations (clear LSDB,...) are separated
> >    
> > from configuration operations (change retransmit-interval),
>  
> > then two different kinds of transaction must be expressed.
> > This will require twice as much text to represent the transaction
> > since the subtree must be duplicated.
> >
> > The configuration operations will be parsed by code that
> > interprets configuration operations, control operations will
> > be processed by code that can interpret control operations.
> >
> > This is necessary because the config operations create a persistent
> > config state file while the control operations are not retained in
> > state.
> >
> > There is more text to exchange in the transaction, more text to parse,
> > and two different parsers to implement.  Assume that the purpose of the
> > control operation is closely related to the config operation.  The two
> > closely related operations are now in separate XML trees in the transaction
> > and it is now less obvious upon reading the transaction that the two operations
> > are closely related. 
> > Furthermore, the management code must accommodate a different syntax for these
> > control command.  More code.
> >
> > Larry
> >    
> Regards,
> /david t. perkins 
>  
--
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>