[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCONF WG meeting minutes for IETF #57

To: netconf@ops.ietf.org
Subject: Re: NETCONF WG meeting minutes for IETF #57
From: Graham Klyne <gk@ninebynine.org>
Date: Wed, 27 Aug 2003 09:44:12 +0100
In-reply-to: <4.3.2.7.2.20030812194018.0249bfb0@fedex.cisco.com>

At 19:41 12/08/03 -0700, Andy Bierman wrote:

Hi,

Here are the minutes for the NETCONF WG meeting held in Vienna.

Here are some thoughts about some of the design directions being suggested...

1) The major issues facing the working group were listed
without much discussion:

  Transport mappings
    BEEP, HTTPS, SSH?

I don't think that BEEP and SOAP should be viewed as mutually exclusive. There is a proposal (somewhere) for SOAP over BEEP. If this means SOAP-over-HTTP, then I think it would help to avoid possible confusion to say this explicitly. If you mean the pre-standard version of SOAP that is specifically HTTP-based, then that should be stated clearly.

  RPC Layer
    SOAP encoding, xmlconf RPC, or simple request/response

This is the *real* possible role for SOAP: SOAP, as currently specified [1], defines SOAP message structures separately from transport bindings.

[1] W3C Weekly News - 27 June 2003:
[[
  SOAP Version 1.2 Is a W3C Recommendation

  The World Wide Web Consortium released SOAP Version 1.2 as a W3C
  Recommendation. The Recommendation is four documents: the "SOAP
  Version 1.2 Primer," "SOAP Version 1.2 Messaging Framework," "SOAP
  Version 1.2 Adjuncts," and the "SOAP Version 1.2 Assertions and Test
  Collection." Developed by the W3C XML Protocol Working Group, SOAP
  Version 1.2 is a lightweight protocol for exchanging structured
  information in a decentralized, distributed environment such as the
  Web. Read the press release, the testimonials, the changes and
  benefits and the FAQ. Visit the Web services home page.

   http://www.w3.org/2003/06/soap12-pressrelease
   http://www.w3.org/2003/06/soap12-testimonial
   http://www.w3.org/2003/06/soap11-soap12.html
   http://www.w3.org/2003/06/soap12faq.html
   http://www.w3.org/2002/ws/
]]

  Advanced XML features
    WSDL templates, XPath filtering, more?

Can WSDL be applied to non-SOAP message structures? (I don't know, but I had the impression that SOAP - in some version - was a prerequisite for using WSDL.)

  Protocol Operations
    Add, Modify, Delete Variants
    Advanced operations: mandatory or optional
    Multi-device operation support
    Error Handling
    Notifications
  Security
    Authorization model, user identity

[...]

There was agreement that XPath support would be a good idea,
but that it should be optional, and a special capability flag
for XPath support is needed.

I would be very wary about using XPath as the basis for selective access to XMLConf data. XPath, by design, provides selection on the syntactic structure of XML: it has been suggested elsewhere (e.g. in the netconf protocol document, IIRC) that the data model is separate from the protocol framework (which I think is a good approach). But the query/selection syntax should be related to the data model, not to the carrier syntax. I have seen difficulties arise with different XML-based applications where people tried to use XPath selection for an XML format used to carry a data model that was somewhat different from the XML carrier syntax. If the data model does not map directly onto the XML syntax, then XPath selection may well prove inadequate to make appropriate selection in the configuration data.

(See also my thoughts about a data model, below.)

2.3) Transport

WSDL over SOAP should be used as the transport binding.

Eh? I thought WSDL is a service *description* language, not a transport binding. The closest I can make sense of this is that WSDL is used to *describe* a transport binding for XMLConf.

New mappings for SOAP over SSH may be defined, and used
in addition to the SOAP over HTTP and SOAP over BEEP
bindings already defined.

Ah, good, these are stated more explicitly.

There were some strong comments from the group on this issue.
There seems to be some significant support for using SOAP
for the transport. NETCONF over BEEP is wrong because this
will cause the WEB Services model to be reinvented.

I'd be interested in a reference that describes *the* web services model. I could maybe accept the above comment about reinventing the web services model if I knew what it meant.

[...]

5.2) Configuration templates

A request was made for configuration template support.
This is an open issue.  It is not clear if this would
be part of the protocol operations, part of the data models,
or both. Perhaps XPath can be used to supply some of this
functionality.

Ouch! That seems like the tail wagging the dog, or a hammer-and-nails position (as in when you have a hammer ...). See above comments about XPath. Perhaps there is a role for XPath eventually, but absent understanding of the requirement I wouldn't want to think about that.

[...]

5.4) 'Get' protocol operation

The XMLCONF draft includes two 'Get' operations, one for
configuration data and one for everything else.  A request
was made to change this scheme.  It should be possible to
retrieve all types of data with a single request.  It
was agreed that a 'get all' type of operation is needed.

IIRC, configuration vs everything else is an issue of static (configuration) data vs dynamic (status) data. Or do I miss something? I do find myself wondering if it is truly possible to draw such a hard-and-fast distinction, and if one has appropriate selection model then the distinction may be redundant. (e.g. if a device IP address is a static assignment obtained by DHCP, which is it?)

[...]


Some thoughts about a data model
--------------------------------

These comments are not presented here as an idea for active consideration by this group, but reflect some private work I have been doing, off-and-on, over the past few months. I raise them here to underscore my concerns about the possible problems of locking the data selection model too closely to the the XML syntactic model in general, and XPath in particular.

I have done a small amount of work to use RDF [2] to represent information about network device configuration and access policies [3]. While my early experiments raised a number of problems using current RDF tools for this purpose, they did also suggest some promising advantages.

RDF is a general purpose language for representing information in the web, which grew out of the PICS (web site metadta) effort, and is now being used in a number of diverse applications, including online resource cataloguing, software agents, message routing, schedule descriptions, etc. It's key features are use of URIs as identifiers, a data model based on a directed, labelled graph, and an XML-based transfer syntax. The design of RDF makes it easy to combine information from various sources into a single expression. It also has a formal semantic structure which provides an initial basis for generic processing of application data. (Roughly, RDF does for application data semantics what XML does for application data syntax: it provides a framework for building upon.)

So why apply the RDF model to network configuration data? My thoughts include: (a) a ready path to include existing SNMP MIB structures (b) fairly direct encoding of entity-relation data models defined using, say, UML (c) easy integration of common standard configuration data with vendor-specific extensions (d) availability of toolkits for processing information (semantic processing as well as syntax handling) e.g. [4] (e) possibilities for using generic tools for direct generation of configuration data from access policy descriptions (this is an area in which I am doing some development work to investigate using Haskell [5] as a "scripting language" for dealing with application data semantics, in particular network configuration and monitoring activities in relation to the user-defined policies for network use).

The above claims beg some justification, which I don't attempt to do here.

My point is to illustrate, in a fairly concrete fashion, the possibility of a data model that is carried in XML syntax, but which does not itself directly reflect the underlying XML data model. XML is (roughly) a labelled-and-annotated tree structure, where RDF uses a labelled directed graph structure. Query/selection that works for a tree structufre doesn't necessarily work for other data models. In the case of RDF, there is a whole raft of experimental work to create a simple query framework, which seems to be rapidly converging on some common core ideas (which happen to considerably simpler than XPath-style selectors) [6].

#g
--

[2] http://www.ninebynine.org/Links.html#RDF

[3] http://www.ninebynine.org/SWAD-E/Intro.html#HomeNetAccessDemo

[4] http://www.ninebynine.org/Links.html#RDF-Tools

[5] http://www.haskell.org/

[6] RDF query work:
    http://www.w3.org/2001/11/13-RDF-Query-Rules/
    http://www.w3.org/TandS/QL/QL98/pp/rdfquery.html
    http://ilrt.org/discovery/2002/04/query/
    http://www-uk.hpl.hp.com/people/afs/Abstracts/ISWC2002-SquishQL-Abstract.html
      http://www-uk.hpl.hp.com/people/afs/Papers/ISWC%202002%20-%20SquishQL.pdf
    etc.


------------
Graham Klyne          _________
GK@ninebynine.org  ___|_o_o_o_|_¬
                   \____________/
(nb Helva)       ~~~~~~~~~~~~~~~~~~   @Reading, River Thames
http://www.ninebynine.org/Travels/2003Aug-Thames/Intro.html


--
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/>

Follow-Ups:
- Re: NETCONF WG meeting minutes for IETF #57
  - From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>

References:
- NETCONF WG meeting minutes for IETF #57
  - From: Andy Bierman <abierman@cisco.com>

Prev by Date: [no subject]
Next by Date: I-D ACTION:draft-wasserman-netconf-over-ssh-00.txt
Previous by thread: NETCONF WG meeting minutes for IETF #57
Next by thread: Re: NETCONF WG meeting minutes for IETF #57
Index(es):
- Date
- Thread