Re: [NGO] Diff-Serv datamodel for discussion startpoint

[Simon Leinen <simon at switch.ch>]

OKITA Hideki writes:
> Dear NGO members,
>   I wrote a draft for the startpoint of NETCONF datamodel discussion.

> 	Title		: A NETCONF Datamodel for Diff-Serv QoS Control Configuration

First of all, thanks! I think that at this point it is very useful to
look at examples like this, because it provides the necessary
"grounding" to discuss the pros and cons of various ways of describing
configurations.

To illustrate this, here is some debate about design decisions in your
particular representation:

1. Flat vs. Deep

At the end of section 3.2.2 (Hierarchical Expression in XML document),
you explain why you decided to use "pointers" (name="foo" attributes
as anchors, and references to these anchors using
e.g. <startElement>foo</startElemend>), as opposed to a "hierarchical"
(or "deep") representation where the referenced tree would just be
included in the place of the reference.

For example, in your "flat" representation you write (abridged example)

       <classifierUnit name='clfu1'>
         <SrcAddr>128.0.1.10</SrcAddr>
         <SrcPrefixLength>16</SrcPrefixLength>
         <nextElement>mkr1</nextElement>
       </classifierUnit>

       <marker name='mkr1'>
         <dscp>46</dscp>
       </marker>

Where a "deep" representation might write this instead:

       <classifierUnit name='clfu1'>
         <SrcAddr>128.0.1.10</SrcAddr>
         <SrcPrefixLength>16</SrcPrefixLength>
         <nextElement>
           <marker>
             <dscp>46</dscp>
           </marker>
         </nextElement>
       </classifierUnit>

You claim that "When parameters of a functional element linked by
multiple elements are changed, operators would meet trouble to change
all elements in the configuration corresponding to the
parameter-changed element respectively."  With XML, I think this is a
particularily weak argument, because there are good (even
standardized) mechanisms for manipulating multiple parts of an XML
document.

There are other arguments for your representation using pointers, for
example:

* It saves space when content is references from multiple places.
* It allows for recursion.  (An excellent first step at making a
  formalism turing-complete :-)

But there are also arguments for "deep" representations

* You don't have to think up names for things that may only be used
  once.
* Everything is placed in the context it is used, which makes it
  easier to understand what a piece of configuration actually does,
  without having to jump around in the configuration "document".

2. Links (pointers) vs. Containers

Related to the flat/deep decision, but a little different:

When you have interconnected elements, you chose a linked
representation, which makes the structure hard to understand (at least
to me).

For example, you write (abridged again):

       <dataPath name='dpth1'>
         <ifIndex>7</ifIndex>
         <ifDirection>in</ifDirection>
         <startElement>clfr1</startElement>
       </dataPath>

       <classifier name='clfr1'>
         <startElement></startElement>
         <classifierUnit name='clfu1'>
           <SrcAddr>128.0.1.10</SrcAddr>
           <SrcPrefixLength>16</SrcPrefixLength>
           <nextElement>mkr1</nextElement>
         </classifierUnit>
       </classifier>

       <marker name='mkr1'>
         <dscp>46</dscp>
       </marker>

Note the startElement pointer from the <dataPath> element to the
<classifier> element, and the nextElement pointer from that
<classifier> to the <marker>.

I claim the structure would be easier to grasp if you wrote

       <dataPath name='dpth1'>
         <ifIndex>7</ifIndex>
         <ifDirection>in</ifDirection>
         <element seq="1">clfr1</element>
         <element seq="2">mkr1</element>
       </dataPath>

       <classifier name='clfr1'>
         <startElement></startElement>
         <classifierUnit name='clfu1'>
           <SrcAddr>128.0.1.10</SrcAddr>
           <SrcPrefixLength>16</SrcPrefixLength>
         </classifierUnit>
       </classifier>

       <marker name='mkr1'>
         <dscp>46</dscp>
       </marker>

This is still flat, but avoids the chain of links.

Of course you can combine this to a deep representation with apparent
structure.  This would be my personal favourite:

       <dataPath>
         <ifIndex>7</ifIndex>
         <ifDirection>in</ifDirection>
         <classifier>
           <classifierUnit>
             <SrcAddr>128.0.1.10</SrcAddr>
             <SrcPrefixLength>16</SrcPrefixLength>
           </classifierUnit>
         </classifier>
         <marker>
           <dscp>46</dscp>
         </marker>
       </dataPath>

(By the way, is the <startElement></startElement> sequence really
necessary in your example?)

In real-world configuration languages we'll probably find all these
variants, plus other smart ways of representing complex
configurations.  That's why I think it is hard to find agreement on
how configuration should be structured.
-- 
Simon.

_______________________________________________
NGO mailing list
NGO at ietf.org
https://www1.ietf.org/mailman/listinfo/ngo