[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NGO] Diff-Serv datamodel for discussion startpoint
Dear Simon,
Thank you for your review and nice comment.
> 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>
Your suggestion seems easier to read than mine. For me, it becomes
a good guideline to use containers to link multiple functional
elements in Diff-Serv configuration.
I hope that it also become the guideline for developers to construct
other models that require multiple references between those objects.
Regards,
Hideki Okita
From: Simon Leinen <simon at limmat.switch.ch>
Subject: Re: [NGO] Diff-Serv datamodel for discussion startpoint
Date: Mon, 19 Mar 2007 16:40:20 +0100
> 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