[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-weijing-netconf-interface-00.txt
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/>