[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation of configuration and control - good or bad?
HI,
On the two parsers, I really didn't mean a SAX and DOM parser, but
parsers for "config messages" and "control messages". There is
LOTS of config and control (status and stats). I hope that I don't
have big GLOBs of code for each type of message. I really want
the processing to scale, so that the OSPF group can write code
independently of the L2 group. With SNMP, even if I'm using
a "monolithic" agent implementation, the different functional
areas can work in parallel.
Also with SNMP, an incremental extension in a functional area
does not impact the message parsing. That is, it is "well contained".
This helps the sanity and health of the testing group.
Don't want to lose these development benefits because to go from
zero to full NETCONF support is only going to happen if all of
the development teams attack the problem.
At 05:19 PM 5/15/2003 -0400, Larry Menten wrote:
>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/>
--
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/>