Subject: [netmod] Representation of instance identifiers

From: <[email-masked]>
Date: Mon, 4 Aug 2008 16:58:53 +0300

Hi Everybody,

in the NETMOD session last Thursday when Martin B. gave an overview
about YANG features,
I'll also touched the issue of the XML representation of an instance
identifier and was
suggesting a different, XML element based representation, which I'm
going to describe here.

In the YANG spec it is currently stated that the instance identifier is
encoded
as XPath expression:
  "The syntax for an instance-identifier is a subset of the XPath
   syntax, which is used to uniquely identify a node in the data tree.
   It is an absolute XPath location path in abbreviated syntax, where
   axes are not permitted, and predicates are used only for specifying
   the values for the key nodes for list entries, or a value of a leaf-
   list.  Each predicate consists of one equality test per key.  Each
   key MUST have a corresponding predicate.

Imho, this way of encoding an instance identifier is a bit to much
biased
in direction of readability but makes creating and parsing instance
identifiers
harder as actually needed (see below).

Therefore I would like to suggest another approach of
encoding an instance identifier, which uses an XML elements.
 - For every node in the location path an XML element with that node
name
   is created in the containing XML element (lead-(list) element)
 - In case the node in the location path is a list
     - a sub-element for every key is created
     - that contains the key value as text

For example the path

  "/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']"

(YANG spec example) would be represented as 

  <ex:system/>
  <ex:server>
     <ex:ip>192.0.2.1</ex:ip>
     <ex:port>80</ex:port>
  </ex:server>

The XPath notation is of course shorter and more easy to read
for humans. But this XPath expressions do not appear in the model
but in NETCONF payload. And this is (mostly) processed by
machines.

* So for a NETCONF agent or manager to make use out of an XPath
expression
  it has to first parse it. That means the agent / manager has to have
an
  XPath expression scanner / parser available that does this job - which
  could mean extra implementation respectively integration
  effort.
  E.g. in the Java 5 platform you have built-in functionality for
  executing Xpath expression on an XML Input source. But that does
  help too much when the referred instance is currently only represented
  in a internal (non-XML) representation (as the referred entity might
  not be part of the XML payload of the actual NETCONF PDU)

* Also encoding instance reference relying on key values
  in form of XPath expressions could be sometimes a bit of a challenge
as
  the quotation mechanism of XPath is a bit limited afaics
  (see XPath http://www.w3.org/TR/xpath#strings, 3.7 [29].

  Consider an e-mail address like

    "John O'Conner"@example.ie

   This is unusual but valid (see RFC 3696).
   Assuming that a node in a list of subscribers
   where the e-mail address is the key must be identified
   by that value. How do you quote it as part of an XPath
   expression? Neither the single-quote form nor the double-quote
   form work in that example.

Having the identifier location path encoded in form of XML elements
as suggested above means
 - that the job of encoding is simple and can be done by only
   using the XML node tree creation API that is anyway used
 - the job of correctly encoding / quoting key values is done
   by the XML processor
 - the job of parsing the elements of the instance identifier
   locating path is done by the XML parser that is anyway used
 - the job of decoding key values is done by the XML parser
 - no need to implement / embed a XPath expression parser for this
   purpose

As this is even the only place where XPath expressions are used
in the NETCONG payload afaics, or...?

So what do you think, wouldn't be an XML element based representation of
instance identifiers be the easier, simpler solution?

Best wishes,
Bernd
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Mon, 04 Aug 2008 08:23:07 -0700

> suggesting a different, XML element based representation, which I'm

This impacts the NETCONF protocol in fields
like the <error-path> element.  It is not very
hard for an agent to generate an XPath expression
for this purpose.  It does not need an XPath parser at all.
It would be more work to generate the entire XML sub-tree
for this purpose.

As for encoding corner-cases, such as the single-quote char.
That's what character entities are for.

Andy

---

From: <[email-masked]>
Date: Mon, 4 Aug 2008 19:13:55 +0300

> -----Original Message-----
> From: ext Andy Bierman [mailto:[email-masked]] 
> Sent: 04 August, 2008 17:23
> To: Linowski Bernd (EXT-Other - DE/Dusseldorf)
> Cc: [email-masked]
> Subject: Re: [netmod] Representation of instance identifiers
> 

Sure - not for generating an XPath expression. Here
you need an builder / or writer.
Still one quote character must be "manually" quoted to ensure valid
XPath expressions.
(E.g. the Java XML Transformer operating on a DOM source does not quote
single or double quotes as part of an element text(!) content -which is
fine
as XML requires only to quote <, >, and & everywhere)

> It would be more work to generate the entire XML sub-tree

I don't agree. Creating the element nodes describing the path is as
least as simple
as building a valid XPath expression. Considering corner cases it even
simpler imho.

But the issue of parsing XPath remains, as an agent might need to
understand
where an instance identifier points.
And you cannot assume that it an up to date copy of its entire
configuration
is available as XML node tree so that you can use an expression
evaluator for that.

To me that looks that functionality needs to be re-invented that is
already provided by
an XML parser in case a XML element based representation is used.

- Bernd

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 05 Aug 2008 17:22:10 +0200

Hello,
I would like to keep the encoding as present. Having big XML structures as the content of a 
simple type sounds ugly to me.

Imagine reading or even more providing as an input the XML structure. Even if Netconf is mainly 
a machine interface it should not become a machine-ONLY interface.

We also got strong comments from operators that protocols, including machine-machine protocols 
should be readable (after decryption).

The syntax for an instance-identifier is only a subset of the XPath so writing and parsing it 
should not be so complicated.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Aug 2008 22:20:47 +0200 (CEST)

Hi,

> harder as actually needed (see below).

I don't agree with this statement.  I don't think that such an
instance identifier is harder to parse than the alternative you
propose.

>   XPath expression scanner / parser available that does this job

I don't agree; an instance identifier happens to be (by design)
valid XPath, but that does not mean that you have to be able to parse
full XPath.  An instance identifier is easily parsed with custom code.

> in the NETCONG payload afaics, or...?

Andy pointed to the error-path element in rpc-error.

/martin