Subject: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Aug 2003 10:36:05 -0400

Graham Klyne posted this note on netconf that has some insights which
I think can benefit us. Pay attention to this statement:

Graham writes:
> 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.

I think this summarizes nicely the concerns I have had about using 
xpath for filtering. I am also going to be removing it from element 
identification in the next xcap-auth rev.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

Subject: Re: NETCONF WG meeting minutes for IETF #57
From: Graham Klyne <[email-masked]>
To: [email-masked]
Date: Wed, 27 Aug 2003 09:44:12 +0100

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          _________
[email-masked]  ___|_o_o_o_|_¬
                    \____________/
(nb Helva)       ~~~~~~~~~~~~~~~~~~   @Reading, River Thames
http://www.ninebynine.org/Travels/2003Aug-Thames/Intro.html

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>