[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-weijing-netconf-interface-00.txt
At 02:19 PM 7/2/2003, Ted Goddard wrote:
I tend to agree with you on many points below, but
before getting into any of that, I would like the
authors of draft-weijing-netconf-interface-00.txt
to explain why they think we should use their draft
as the starting point instead of the xmlconf draft.
The charter says we will use the xmlconf draft as
a starting point. I personally don't see any
real advantages, and in some cases a lack of
specificity that would make multi-vendor
interoperability less likely.
As for the netconfsoap draft, this does not really
conflict with the xmlconf draft. It addresses the
transport issue, which is totally open at this time.
Andy
>Hi Keith,
>
>On Wednesday, July 2, 2003, at 09:07 AM, Allen, Keith wrote:
>>Thanks for your interest in and comments on
>>draft-weijing-netconf-interface-00.txt. You're right; it was a response
>>to xmlconf-spec. I think the examples in netconf-interface fit easily
>>within the xmlconf-spec because we wanted to use examples with which
>>people are familiar.
>
>My approach in the following will be to try to accommodate your
>concerns within the framework of draft-enns-xmlconf-spec-00.txt
>(xmlconf-spec). To do this, I've allowed a few compromises on
>xmlconf-spec that I'm interested in people's comments on:
> 1. Consider an optional XPath-based <get-config>
> 2. State vs configuration is an attribute
> 3. Consider optional fine-grained locking
>
>> We do feel, however, that despite the wording in
>>the charter that states the group will focus on protocol issues, the
>>xmlconf-spec actually specifies quite a bit in the way of information
>>modeling. The forced separation of information into configuration and
>>state information is probably the most glaring example of this.
>
>I think a case can be made for not distinguishing between "configuration"
>and "state" by using different operations for each. Two other possible
>mechanisms would be to distinguish via "configuration" or "state"
>attributes, or to place "configuration" and "state" in separate
>subtrees. From your comments below, I believe you're leaning towards
>the use of attributes to distinguish. The query mechanism described
>in xmlconf-spec is convenient for simple queries, but is not as
>powerful as something one might imagine based on XPath. Perhaps a
>device that supported an optional XPath-based "<get-config>" could
>indicate this with a capability (an XPath-based mechanism would easily
>allow queries based on attributes).
>
>> There
>>had also been quite a bit or arguing over the granularity of locking,
>>which again we feel is an information model issue. While we support the
>>development of standard information models, we feel this should be
>>pursued as a separate effort from the protocol, and feel that the
>>xmlconf-spec will unduly limit that effort and thus the application of
>>the protocol itself.
>
>Shouldn't it be possible to agree on a locking scheme independently from
>the information model (which definitely must be a separate effort)?
>xmlconf-spec currently specifies a single lock per configuration, but
>finer-grained locks within configurations have been discussed. Locking is
>already an optional capability; perhaps there should there also be an
>optional fine-grained lock in the base specification. However, there
>were concerns that with fine-grained locking it is difficult for the
>application to reliably know exactly how much to lock, and the burden
>on the agent writer would be greater.
>
>
>>If you look at other network management protocols that separate
>>information models from the protocol, you see pretty generic operations.
>>Get (with some variations) and set in SNMP; get, set, create, delete,
>>and action in CMIP. We don't see anything wrong with taking a similar,
>>generic approach with XML.
>
>The basic operations are present in xmlconf-spec, but through its additional
>features, much more sophisticated management should be possible.
>
>>In response to your questions/comments:
>>
>>>>1.
>>
>>>>It is implied that WSDL is generic enough to describe
>>>>the SSH and BEEP bindings as well as the SOAP binding. This
>>>>may be reasonable in the future, but neither BEEP nor SSH are
>>>>currently included in the WSDL specification, and neither BEEP
>>>>nor SSH is currently supported by WSDL tools. BEEP and SSH are
>>>>useful transports, but they are not easily captured by WSDL
>>>>today.
>>
>>You're right. Hopefully, someday we will be able to describe SSH and
>>BEEP bindings in WSDL but in the mean time they will probably have to be
>>"hand written." It is our hope that tool vendors that specialize in
>>network management will provide netconf toolkits. Perhaps they will
>>help to develop WSDL descriptions for SSH and BEEP if that makes sense.
>
>That's reasonable, although there are multiple steps as you describe (with some
>parallelism possible):
> 1. Extend WSDL
> 2. Use extended WSDL in netconf spec
> 3. Develop extended WSDL-based tools
> 4. Develop WSDL-based BEEP and SSH netconf applications
>
>>>>2.1.1
>>
>>>>By placing the "operation" as an attribute on the <perform-request>,
>>>>there is reduced opportunity for schema validation on the operation.
>>>>In contrast, this is an important form of type-checking in
>>xmlconf-spec.
>>
>>I ask that you be more specific here. Since the operation is an
>>enumeration, it can be checked for validation. We feel it is important
>>that the xml management messages be checked for validity against both
>>the message schema (the "netconf part") and the information model
>>schema.
>
>For instance, the following would be valid:
>
><perform-request operation="get">
> <n:set xmlns:n="some-namespace"/>
></perform-request>
>
>The string used in the "operation" attribute can be restricted to
>an enumeration as you have done, but I believe it is difficult
>within XSD to associate the attribute value with the allowed
>contents of an element.
>
>>>>Why are "get-readwrite" and "get-readonly" special types of actions?
>>>>Perhaps the elements in the data model should have read/write
>>attributes
>>>>and the value of this attribute should be specified in the query?
>>
>>This was done as an alternative to the separate "get-state" operation in
>>xmlconf-spec. We feel that defining separate information model schema
>>for configuration and state information will be too burdensome. It is
>>much more likely, for example, that "administrative state" (a
>>configurable parameter) and "operational state" (a state parameter) will
>>both be elements of "interface" rather than having separate
>>"interface-state" and "interface-config" definitions, one containing the
>>state parameters under the <state> information model tree and one
>>containing configurable parameters under the <config> tree. (If you
>>don't define separate schema, then it's just weird. If I want to
>>retrieve the operational state of an interface I use the "get-state"
>>operation on one "path" identifying the interface, and if I want to get
>>the administrative state of the same interface I use a different
>>operation on a different path. How do I know which to use when?)
>>
>>We do, however, like the idea of being able to retrieve just the
>>configurable parameters of a system, so that they may be stored. In the
>>example above, "administrative state" would be defined as "readwrite"
>>while "operational state" would be defined as "readonly," just as you
>>suggest. (We feel it is quite reasonable to expect the information
>>model schema to define which parameters are readable and which are
>>writable.) Thus, a get-readwrite operation on an interface element
>>would include "administrative state" in its return, while a get-readonly
>>would include "operational state." It's sort of a crude filtering
>>capability, to specifically support a means of retrieving configuration
>>data without state info. I guess, strictly speaking, get-readonly may
>>not be needed, but we included it for completeness.
>
>As I described above, perhaps a reasonably sophisticated (but optional)
>filtering capability (such as one based on XPath) should be considered?
>
>>>>2.3
>>
>>>>A rich data model for capabilities is appealing, but using such
>>>>fine-grained control could greatly increase application complexity.
>>
>>I would say the capabilities schema is open for discussion, but it is
>>really the beginning for defining a standard information model. It
>>depends on how broad the range of devices you want to be manageable with
>>the protocol. Very simple devices will support only the minimum, while
>>more complex devices will be expected to support more. It's important
>>that a management application, though, be able to determine what the
>>capabilities of the device are.
>
>General capabilities of the device or just capabilities with respect
>to the netconf protocol?
>
>Regards,
>Ted.
>
>
>
>>Keith Allen
>>SBC Labs
>>9505 Arboretum Blvd.
>>Austin, TX 78759
>>(512) 372-5741
>>keith_allen@labs.sbc.com
>>
>>
>>-----Original Message-----
>>From: Ted Goddard [mailto:ted.goddard@windriver.com]
>>Sent: Tuesday, July 01, 2003 5:41 PM
>>To: netconf@ops.ietf.org
>>Subject: Re: I-D ACTION:draft-weijing-netconf-interface-00.txt
>>
>>
>>Hi All,
>>
>>I have a few comments on draft-weijing-netconf-interface-00.txt.
>>
>>The documents relating to this discussion are:
>>
>> draft-enns-xmlconf-spec-00.txt (xmlconf-spec)
>> draft-goddard-netconfsoap-00.txt (netconfsoap)
>> draft-weijing-netconf-interface-00.txt (netconf-interface)
>>
>>In terms of scope, netconf-interface addresses a subset of what is
>>addressed in xmlconf-spec. Both netconfsoap and netconf-interface
>>exhibit SOAP-based techniques for device management, but netconfsoap
>>extends xmlconf-spec while netconf-interface requires new
>>management operations.
>>
>>If netconf-interface is taken as a response to xmlconf-spec, the
>>interpretation could be that the xmlconf-spec semantics (such as
>>for manipulating configurations) are seen to be not generic enough;
>>yet all of the examples in netconf-interface easily fit into the
>>xmlconf-spec model. If there are use cases that break xmlconf-spec,
>>they should be presented; otherwise, it may be that xmlconf-spec is
>>already generic enough.
>>
>>The Abstract of netconf-interface posits that multiple transports
>>(such as SOAP and SSH) should be supported. By itself this is
>>reasonable, but it does not provide justification for making the
>>operations themselves more generic, as this comes at the expense of
>>interoperability.
>>
>>1.
>>
>>It is implied that WSDL is generic enough to describe
>>the SSH and BEEP bindings as well as the SOAP binding. This
>>may be reasonable in the future, but neither BEEP nor SSH are
>>currently included in the WSDL specification, and neither BEEP
>>nor SSH is currently supported by WSDL tools. BEEP and SSH are
>>useful transports, but they are not easily captured by WSDL
>>today.
>>
>>2.1.1
>>
>>By placing the "operation" as an attribute on the <perform-request>,
>>there is reduced opportunity for schema validation on the operation.
>>In contrast, this is an important form of type-checking in xmlconf-spec.
>>
>>Why are "get-readwrite" and "get-readonly" special types of actions?
>>Perhaps the elements in the data model should have read/write attributes
>>and the value of this attribute should be specified in the query?
>>
>>2.3
>>
>>A rich data model for capabilities is appealing, but using such
>>fine-grained control could greatly increase application complexity.
>>
>>Regards,
>>Ted Goddard.
>>
>>
>>
>>
>>On Friday, June 27, 2003, at 01:33 PM, Chen, Weijing wrote:
>>
>>>Forwarding the following announcement from IETF announcement list.
>>>
>>>
>>>
>>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>
>>>
>>>
>>>
>>>
>>> Title : XML Network Management Interface
>>>
>>> Author(s) : W. Chen, K. Allen
>>>
>>> Filename : draft-weijing-netconf-interface-00.txt
>>>
>>> Pages : 23
>>>
>>> Date : 2003-6-26
>>>
>>>
>>>
>>>This document describes XML network management interface between
>>>
>>>network managed system and network managing system. The XML network
>>>
>>>management interface is intended for use in diverse network
>>>
>>>environment where transport and data model requirements vary
>>>
>>>greatly. It is unlikely that a single transport and data model
>>>
>>>specification will meet the needs of all anticipated service
>>>
>>>operators. Therefore, the XML network management interface is
>>>
>>>partitioned into the layered components.
>>>
>>>
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-weijing-netconf-interface-
>>>00.t
>>>xt
>>><http://www.ietf.org/internet-drafts/draft-weijing-netconf-interface->> 00.
>>>txt>
>>>
>>>
>>>
>>>To remove yourself from the IETF Announcement list, send a message to
>>>
>>>ietf-announce-request with the word unsubscribe in the body of the
>>>message.
>>>
>>>
>>>
>>>Internet-Drafts are also available by anonymous FTP. Login with the
>>>username "anonymous" and a password of your e-mail address. After
>>>logging in, type "cd internet-drafts" and then
>>>
>>> "get draft-weijing-netconf-interface-00.txt".
>>>
>>>
>>>
>>>A list of Internet-Drafts directories can be found in
>>>http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>>>
>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>
>>>Weijing Chen
>>>
>>>
>>
>>
>>--
>>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/>
--
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/>