Re: [netmod] Y34 - root node

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Tue, Aug 4, 2015 at 2:34 AM, t.petch <[e-mail]> wrote:
>
>> ----- Original Message -----
>> From: "Andy Bierman" <[e-mail]>
>> To: "t.petch" <[e-mail]>
>> Sent: Monday, August 03, 2015 5:17 PM
>>
>> > ----- Original Message -----
>> > From: "Andy Bierman" <[e-mail]>
>> > To: "t.petch" <[e-mail]>
>> > Sent: Monday, August 03, 2015 4:10 PM
>> >
>> > > ----- Original Message -----
>> > > From: "Andy Bierman" [e-mail]
>> > > Sent: Saturday, August 01, 2015 7:05 PM
>> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <[e-mail]>
>> > >
>> >>> On 8/1/15, 2:51 AM,  [e-mail]> wrote:
>> >>>
>> >>> Section 1.1 in
>> >>>
>> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
>> >>> lists the goals of a generic model structure that will accommodate
>> >> most
>> >>> modern network devices. I guess you don’t agree that these are
>> >> desirable?
>> > >
>> > > The only objection I have to this draft is the insertion of a
>> top-level
>> > > root
>> > > called "device".  (Might as well be called "self").
>> > > There are no sibling nodes planned or intended for
>> > > this node, so it serves as an extra document root.
>> > >
>> > > <tp>
>> > > One aspect of YANG I have never grasped is what a root means, if
>> > > anything.
>> > >
>> > > I understand that it is needed for NETCONF (filters) and for YANG
>> > > (augments, constraints) and so must be somewhere and must be
>> > relatively
>> > > stable, but has it any other significance in the data model?
>> > >
>> > > As you may recall, I was involved with SMI first, where the root is
>> > > somewhere up in the sky and life only becomes interesting some six
>> > > levels down the hierarchy and that may colour my thinking.
>> > >
>> >
>> > YANG does a poor job of defining the root for YANG data nodes.
>> > It is sometimes called a datastore (in the abstract).
>> > Technically, YANG borrows the definition from XPath.
>> > YANG just defines top-level data nodes and the parent of
>> > these nodes is the document root.
>> >
>> > There is no protocol or encoding neutral definition,
>> > only an XML-specific definition.
>> >
>> > <tp>
>> >
>> > Thanks for that.
>> >
>> > It seems to me that much of the extensive discussion on Y34 (all of
>> > which I have read) is as much political as technical, that is SMI is
>> > hierarchical, top down, perhaps befitting its origins in ISO, whereas
>> > YANG is bottom up. IETF-like.  YANG could have had a single tree, but
>> > doesn't.  So when I read
>> >
>> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
>> >
>> > I see a plea for a more hierarchical organisation, and when I read
>> >
>> > draft-bjorklund-netmod-openconfig-reply-00
>> >
>> > I see a response that says we are not like that.
>> >
>> > If so, I doubt that there ever will be a technical solution.
>> >
>> > And I am mindful that when I configure routing in a (Cisco) router, I
>> > have to do some of it under the interface definitions and some of it
>> > under the definition of the routing protocol.  Which is life, never
>> > wholy interface-centric and never wholy routing protocol-centric!
>>
>> Are you saying the job would be easier if the
>> path was /device/interfaces/interface instead
>> of just /interfaces/interface?  Are you saying
>> that /protocols/routing could not also be defined?
>> Clearly edit-config and copy-config allow both
>> subtrees to be accessed in the same operation,
>> so I don't understand your concern.
>>
>> I have been trying to get the root node to be better defined
>> in the protocols that use YANG (i.e., ncx:root, Y34-04).
>> IMO this is a better approach than defining a YANG module
>> with a special container that all other modules are expected
>> to augment.  YANG is designed such that each vendor or SDO
>> is not dependent on other vendors or SDOs in order to
>> define data nodes.
>>
>> <tp>
>>
>> Andy
>>
>> I am agreeing with you that adding 'device' brings no technical benefit,
>> rather that the motivation is the opposite of technical (which I
>> referred to as political). I am also agreeing with the current declared
>> consensus on Y34.
>>
>> And yes, YANG is going to give us a large number of modules, some
>> tightly coupled (augments) some loosely so (how many do you need to
>> configure OSPF?) and work in this area will be of benefit now and
>> probably essential in a few years time.  That said, I am unsure what
>> such work would be like; I am looking (in despair) at 50 routing area
>> YANG models and wondering how a user will ever get a coherent picture of
>> how to do what they want to do.
>>
>>
>
> The "YANG Land Grab" gives a false sense of progress.
> Reaching WG consensus on every single leaf is hard work.
>
> I don't think a collection of 100s of YANG modules is ever
> going to to be easy to understand.  Operators will not examine
> a NETCONF <hello> message, look at 150 module URIs,
> and say "I know exactly what this device supports".
> I guess it is up to client tools to do that.
>
> I wrote a draft that defines YANG Packages, which can provide
> a higher level of organization for YANG modules.
>
> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>
> You and I are apparently in the minority, since the official status
> is that there is no problem with the current approach, and no need
> to organize individual YANG modules into any larger abstractions.
>

I believe most people agree something like this is needed, and the
attempt to clarify import semantics in YANG 1.1 isn't meant as a
replacement for packages.

Lada

>
>
>  Tom Petch
>>
>>
>
> Andy
>
>
>> Andy
>>
>> > Andy
>> >
>> > > The well-specified XPath and YANG root (/) can be
>> > > accessed by all protocol operations, exactly the same
>> > > as a node called 'device'.  The actual node name will
>> > > depend on the RPC function (e.g. 'data' or 'config').
>> > >
>> > > This is more than redundant however.  It introduces a "super-module"
>> > > into YANG that every other module is expected to augment.
>> > > YANG is intended to be more loosely coupled than that.
>> > > This introduces an extra node and namespace declaration
>> > > in all protocol messages, increasing message sizes.
>> > >
>> > > It also assumes all existing YANG models will get rewritten to
>> > > account for "/device" in all path and XPath expressions.
>> > > This is highly disruptive to existing deployments.
>> > > Also, multiple data models to edit the same thing causes lots
>> > > of extra complexity in the server (supporting both old
>> > > location and new location).
>> > >
>> > > IMO a resource directory approach is much more realistic.
>> > > The /device tree can contain all the organized NP containers.
>> > > Instead of all the actual data nodes, this tree just has pointers
>> > > to the real location of the resource. (like 301 Moved Permanently)
>> > >
>> > > > Acee
>> > > >
>> > > Andy
>>
>>
>> ** Solution Y34-02
>>
>>   Keep 'anyxml'.  Introduce 'anydata' as above but without the
>>   'format' substatement.
>>
>>   'anyxml' would still be used to represent unrestricted XML, as is
>>   done in NETCONF.
>>
>>   'anydata' would be an unknown chunk of data that can be modelled
>>   with YANG.  Can be encoded as xml or json.
>>
>>   For example:
>>
>>     #+BEGIN_EXAMPLE
>>     anydata data;
>>     #+END_EXAMPLE
>>
>> ** Solution Y34-05
>>
>>    Same as Y34-02 plus two guidelines adopted from Y34-04:
>>
>>    - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This
>>      ensures backward compatibility.
>>    - Introduce a new 'anydata' statement that represents an unknown
>>      chunk of data that can be modeled with YANG
>>    - Document that implementations MAY have restrictions for anyxml and
>>      that anyxml is not necessarily interoperable; data model writers
>>      should use anydata whenever possible.
>>    - The guidelines document should say that YANG Doctors will review
>>      each use of anyxml in IETF modules when YANG 1.1 is adopted to
>>      avoid its use whenever possible.
>>
>>
>> >
>>
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C