[Hand-approved because the sender address was different from the
subscription address. Sorry for the delay-- Simon.]
Ted,
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. 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. 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.
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.
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.
>> 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.
>> 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.
>> 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.
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/>
<<application/ms-tnef>>