[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D draft-weijing-netconf-interface-01.txt
> Not exactly. In the first example, the get-config operation
> is restricted to the running configuration. In the second
> example, there is nothing preventing the user from including:
> <running>
> <users/>
> </running>
> <startup>
> <users/>
> </startup>
> This distinction is much more important for edit-config
> than get-config. Also, in both cases the concepts of
> running, startup, and candidate must be known to the
> application and the device.
Yes, there is a way to prevent the user to do that if you desire by using
XML "choice" instead of "sequence". However, some device may support the
exact behaviour you describe. This is exact the reason that we propose
separating the protocol from data model.
> I disagree. The concepts of candidate, running, and startup
> are well-established and stable within the industry. In the
> unlikely event that another type of configuration database
> is needed in the future, the netconf protocol can be updated.
> This is a trade-off between interoperability and flexibility.
> I prefer a precise protocol that promotes interoperability.
Well-estabilished maybe in the router industry, not quite so regarding a lot
of other type equipments (DSL, FTTP, SONET, DWDM, ATM, etc.) The evolution
by protocol will bring more backward compatiblity issue than evolution by
data model.
> The WG agreed in Vienna that some form of a 'get-all' mechanism
> is needed so 2 requests are not needed to retrieve config and state
> information.
So a third protocol operatation other than "get-config" and "get-state". I
don't think it is simple and clean.
> I disagree. The operations defined in netconf such as copy,
> validate, and lock are well-understood operations on an abstract
> database. They are not specific to the content of the database at all.
> This is another trade-off between interoperability and flexibility.
> Allowing vendors to define their own set of protocol operations,
> potentially a different set for every data object, would be a
> disaster for interoperability and code reuse. Your proposal
> does not remove complexity -- it just moves it into the
> proprietary data models.
The "lock" is not a database lock. It has not rollback semantics in the WG
text. Our draft specifies the "Action" type with the following values: nop,
create, delete, replace, merge, copy, validate, clock, unlock. Data model
designe is allowed to extend or restrict the permittable actions. We can
discuss what is the proper base set of values.
> Perform is too generic. Abort is broken because there is no
> support for multiple streams (channels or multiple connections.)
> Notify is also broken without support for multiple streams.
> I don't think removing the <rpc> and <rpc-reply> elements
> actually make implementations easier.
Perform is no more generic that "edit-config" in WG text. They all use
"action-as-attribute". The multiple streams or connections is the transport
mapping issues. Abort or notif can be mapped onto different channels if
transport supports it. However, multiple channels does not really help to
abort or notif. In a single thread application, multiple channels doesn't
easy the blocking. In a multithread application, single channels doesn't
block.
> I think your draft glosses over a lot of important details
> and punts even more details to proprietary data models.
> This is not simpler, especially if you want to write an
> application that will work with devices from lots of vendors.
>
Network management isn't easy, otherwise we won't be here today. I agree
that the information must be in somewhere. We just don't think information
should be in protocol as in the WD text.
--
Weijing Chen
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Tuesday, September 02, 2003 5:18 PM
> To: Allen, Keith
> Cc: netconf@ops.ietf.org
> Subject: Re: I-D draft-weijing-netconf-interface-01.txt
>
> At 02:21 PM 9/2/2003, Allen, Keith wrote:
> >All,
> >
> >Below is a reference to an Internet Draft we have authored to illustrate
> a
> >somewhat different approach to the NETCONF XML protocol than the one
> taken
> >in the working group's current working text.
> >
> >http://www.ietf.org/internet-drafts/draft-weijing-netconf-interface-
> 01.txt
> >
> >We have some concerns about the protocol specified in the current WG text
> so
> >we created the I-D as a contribution to the upcoming working group
> interim
> >meeting to show how these concerns could be addressed. (We felt
> discussing
> >an example would be easier than arguing abstract concepts.) Our specific
> >concerns with the current WG text are:
> >
> >1. Assumptions about a device's information model are being built
> into
> >the protocol. One way this is manifested is with the protocol's use of
> >"targets." The specification of "startup," "running," and "candidate"
> >targets presumes that the device supports these concepts.
>
> All devices have a running config.
> Based on the device capabilities, it may also support a
> candidate config and/or a distinct startup config.
>
> > This need not be
> >the case, and the protocol does not benefit from having this built in.
> >Consider two examples below (the first is from the WG text):
> >
> > <get-config>
> > <source>
> > <running/>
> > </source>
> > <config xmlns="http://example.com/schema/1.2/config";>
> > <users/>
> > </config>
> > <format>xml</format>
> > </get-config>
> >
> >
> > <get-config>
> > <config xmlns="http://example.com/schema/1.2/config";>
> > <running>
> > <users/>
> > </running>
> > </config>
> > <format>xml</format>
> > </get-config>
> >
> >They both say the same thing: get the user data from the running
> >configuration.
>
>
> >A separate "source" element containing the target is
> >unnecessary, and building the acceptable target values into the protocol
> is
> >restricting and could come back to haunt us. The specification of a
> >"running," "startup," or other target should be part of a device's
> >information model schema.
>
>
> >2. Another way that assumptions about the device's information model
> >are being built into the protocol is with many of the operations being
> >specified in the protocol, like "copy," "validate" and "lock." This is
> >probably the biggest difference between the WG text and our draft. Our
> >suggestion is to associate operations with elements in the information
> model
> >in what we consider to be a more object-oriented approach. In our draft,
> >the information model elements that could be considered "objects" have an
> >attribute listing the possible actions that can be invoked on that
> element.
> >(This has been discussed on the e-mail group as "action as attribute."
> The
> >WG text uses this to a degree, but we take it a significant step
further.)
> >Our draft lists a set of "standard" operations (that includes actions
> like
> >"copy," "validate" and "lock") but this list can be restricted or
> extended
> >in a particular device's information model specification. The protocol
> >needs to be flexible and extensible to allow for the management of both
> >simple and complex devices.
>
> I disagree. The operations defined in netconf such as copy,
> validate, and lock are well-understood operations on an abstract
> database. They are not specific to the content of the database at all.
> This is another trade-off between interoperability and flexibility.
> Allowing vendors to define their own set of protocol operations,
> potentially a different set for every data object, would be a
> disaster for interoperability and code reuse. Your proposal
> does not remove complexity -- it just moves it into the
> proprietary data models.
>
>
> >3. The handling of "state" and "config" information in the WG text
> is
> >inadequate. The information model specified for a device must identify
> what
> >is state information and what is configurable without the need for
> separate
> >container elements. Our draft defines a way to do this by tagging each
> >element definition in an XML information model with a "category"
> indicating
> >whether the element is state information or configuration data. The same
> >category tag can be included in the get request message to act as a crude
> >filter, retrieving just state information, just configuration
information,
> >or both.
>
> The WG agreed in Vienna that some form of a 'get-all' mechanism
> is needed so 2 requests are not needed to retrieve config and state
> information.
>
>
> >4. This is not a major point, but the "format" element in the WG
> text
> >is unnecessary. A more straightforward approach for devices that don't
> >support a true XML interface would be to enclose the CLI text supported
> by
> >the device with a single pair of XML tags. Thus, the device's
> information
> >model schema can indicate that the text between the two tags will be
> >untagged.
>
> I agree with this point. A <text> tag would also allow for
> mixed content (XML conforming to a detailed XSD and embedded
> CLI).
>
>
> >5. Removing some of the complexity from the protocol results in just
> a
> >few simple operations the protocol must support. In our draft, we have
> just
> >four command messages and four responses to those messages: get, perform,
> >abort and notify. With just four operations, we don't feel it is really
> >necessary to define a separate RPC layer as the WG text does.
>
> Perform is too generic. Abort is broken because there is no
> support for multiple streams (channels or multiple connections.)
> Notify is also broken without support for multiple streams.
> I don't think removing the <rpc> and <rpc-reply> elements
> actually make implementations easier.
>
>
> >Pulling up the schema from the two drafts in an editor shows that the
> >protocol can be trimmed down quite a bit. There are just 8 elements
> defined
> >in our draft, versus over 30 in the WG text. Of course, some of the
> >complexity is being shifted to the information model, but we still feel
> that
> >the "simpler is better" doctrine applies.
>
> I think your draft glosses over a lot of important details
> and punts even more details to proprietary data models.
> This is not simpler, especially if you want to write an
> application that will work with devices from lots of vendors.
>
>
> >Our hope is that you will take a look at the draft and consider the
> approach
> >we have taken. We think there is a lot to be said for a protocol that is
> >simpler, and takes a more object-oriented approach towards operations.
> We
> >hope to get an opportunity to discuss these ideas with you at the interim
> >meeting next week, and to hopefully address our concerns with the current
> >working text.
>
> I agree that everyone should read this draft, and all the other
> drafts that have been proposed to the WG. I hope we can resolve
> the issues you raised on the mailing list or at the interim
> meeting next week.
>
>
> >Keith Allen
> >SBC Labs
> >9505 Arboretum Blvd.
> >Austin, TX 78759
> >(512) 372-5741
> >keith_allen@labs.sbc.com
> >
> >Weijing Chen
> >SBC Labs
> >9505 Arboretum Boulevard
> >Austin, Texas 78759
> >(512) 372 5710
> >wchen@labs.sbc.com
>
> Andy
>
>
> --
> 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/>