[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: netconf WG charter proposal
At 04:56 PM 4/5/2003 -0700, John Strassner wrote:
>I agree with Juergen's first three comments - remove "robust transaction model" and replace with his rewording, remove the RPC statement, and reword the data representation statement.
>
>Regarding the following:
>
>Andy> - Provides support for multi-device configuration transactions
>Andy> (with locking and rollback capability)
>
>Why is this just "multi-device"? Clearly, there are operations on a single device (even a single interface) that take some time to setup and perform, so simply blasting a set of commands down to an interface won't always work.
Could you suggest some text to add to the charter?
I agree there are some single box transaction requirements,
like the ability to validate config before applying it, or
applying all the commands or none of them.
>Regarding the following:
>
>Andy> - XML namespace conventions
>Andy> - XML usage guidelines
>
>First, I agree with Juergen - the charter should state that XML will be used up front. Second, while XML namespace conventions are in general a Good Thing, they were left somewhat broken in the 99 issue of the namespace Recommendation of the W3C because DTDs (among other things) were also broken. For example, validation of namespaces is problematic, though it is being worked on by the XML Schema WG. So, I have two questions. First, how up-to-date do you want this charter to be? In other words, is the W3C namespace recommendation from 99 "good enough", or do you want to try and use newer work? Second, what do you mean by "XML usage guidelines"?
Look at rev B of the charter proposal. I added text.
XML usage guidelines seems to be controversial. There
are features in the XML spec that are not likely to be
supported on embedded network devices. The XMLCONF draft
suggests we restrict our usage of XML to Canonical XML
defined in RFC 3076. (This is not what the charter says BTW)
>Andy> Although it should be possible to transport the Netconf protocol
>Andy> using several different protocols, the group will initially define
>Andy> a mapping for the Blocks Extensible Exchange Protocol
>Andy> (BEEP) [RFC 3080]. Future work may standardize other transport
>Andy> mappings.
>
>I agree with Juergen, why is this being done?
The XMLCONF design team looked at several choices and
decided BEEP was the best one to use. I'll ask you
the same question I asked Juergen. If you don't want
to use BEEP then what should we use instead? This isn't
a rhetorical or abstract question. Suggest a real protocol
to use instead.
>regards,
>John
Andy
>
>John Strassner
>Chief Strategy Officer
>Intelliden Corporation
>90 South Cascade Avenue
>Colorado Springs, CO 80903 USA
>phone: +1.719.785.0648
> FAX: +1.719.785.0644
>email: john.strassner@intelliden.com
>
>
>-----Original Message-----
>From: Juergen Schoenwaelder [<mailto:schoenw@ibr.cs.tu-bs.de>mailto:schoenw@ibr.cs.tu-bs.de]
>Sent: Friday, April 04, 2003 10:01 AM
>To: abierman@cisco.com
>Cc: xmlconf@ops.ietf.org
>Subject: Re: netconf WG charter proposal
>
>
>>>>>> Andy Bierman writes:
>
>Andy> The Netconf Working Group is chartered to produce a protocol
>Andy> suitable for network configuration, with the following
>Andy> characteristics:
>
>Andy> - Has a robust transaction model, based on remote procedure
>Andy> calls (RPC)
>
>I think I would agree with "the protocol must have the primitives to support network wide configuration transactions". Just saying "robust transaction model" might lead to nasty discussions later on. Furthermore, I do not understand why the charter requires RPCs. And in fact, JunoScript and xmlconf both seem to be just request/response protocols very similar to SNMP by the way. I fail to see real support for RPC abstractions in the classic sense. I suggest just to drop the text about RPCs - I do not find it convincing or helpful.
>
>Andy> - Uses a data representation that is easily manipulated
>Andy> using non-specialized text manipulation tools
>
>So XML is out if I take that text serious. XML documents have structure and to really operate on them, you need to have tools that understand the structure. The good news is that there is an increasing amount of such tools.
>
>Andy> - Provides support for multi-device configuration transactions
>Andy> (with locking and rollback capability)
>
>So I probably mis-understood what the robust transaction model above was. This probably indicates a need for clarification. Anyway, does this item imply that locking and rollback capabilities are a required feature? If yes, I applaud (and look forward for an xmlconf revision that actually makes this mandatory).
>
>Andy> - Suitable for IP-reachable network devices
>
>Are you saying the protocol runs finally over IP? This is what everybody expects anyway, right?
>
>Andy> - XML namespace conventions
>Andy> - XML usage guidelines
>
>If it is agreed that XML is the data encoding, then say so upfront rather than bringing it is sideways.
>
>Andy> Although it should be possible to transport the Netconf protocol
>Andy> using several different protocols, the group will initially define
>Andy> a mapping for the Blocks Extensible Exchange Protocol
>Andy> (BEEP) [RFC 3080]. Future work may standardize other transport
>Andy> mappings.
>
>I do not recall that the operators were loudly asking for BEEP. So why is this initial (and I guess default) transport mapping already determined by the charter?
>
>Andy> The working group will use the XMLCONF Configuration Protocol
>Andy> <draft-enns-xmlconf-spec-00.txt> as the starting point for this
>Andy> work.
>
>Personally, I would think that using JunoScript would be an even better base since it is a deployed protocol and does not suffer from the many options that were introduced in the xmlconf variation.
>
>/js
>
>--
>Juergen Schoenwaelder <<http://www.iu-bremen.de/>http://www.iu-bremen.de/>
>
>--
>to unsubscribe send a message to xmlconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
>
>archive: <<http://ops.ietf.org/lists/xmlconf/>http://ops.ietf.org/lists/xmlconf/>
--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>