Subject: Re: [netmod] Y34

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 1 Aug 2015 16:51:28 +0000

Hi Juergen, 

On 8/1/15, 2:51 AM, "netmod on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of
[email-masked]> wrote:

>On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote:
>> Andy,
>> 
>> On 07/27/2015 12:58 PM, Andy Bierman wrote:
>> > Hi,
>> > 
>> > I don't think a standard for relocating subtrees would be worth it.
>> > I am not in favor of moving /interfaces or /system to a new location.
>> > That's not how YANG works. It only allows "obsolete and start over".
>> > 
>> > I would suggest pursuing solutions that don't cause
>> > as much disruption and expense as possible.
>> > 
>> 
>> I think it would be really good to explore other, less "disruptive"
>> options.
>>
>
>I think the first step is to find out whether there is a problem worth
>to be fixed. Why are the RFCs in question broken? (Yes, I have read
>the openconfig IDs,

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?

Thanks,
Acee 

>I listened to the virtual interim meetings, I
>assume you have read draft-bjorklund-netmod-openconfig-reply.)

>
>Lets get the core of the openconfig argument on the table why the
>existing RFCs are flawed.
>
>/js
>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 Aug 2015 19:23:27 +0200

> modern network devices. I guess you don’t agree that these are desirable?

   o  a common schema to access data related to all aspects of a device

This is why we produce standards. They are a common schema.

   o  an extensible structure that makes it clear where additional
      models or data should be fit (e.g., using YANG augmentation or
      imports)

This is why we have /interfaces. Interface related stuff goes here.
It is easy to reference.

   o  a place for including metadata that provides useful information
      about the corresponding individual models, such as which
      organization provides them, which vendors support them, or which
      version of the model is deployed

Not really sure what this means. YANG modules have meta data. A
NETCONF or RESTCONF server exposes which data models it implements. A
list of which vendor supports what is clearly outside the scope of
IETF work.

   o  a common infrastructure model layer on which higher layer service
      models can be built, for example by specifying which models are
      needed to provide the service

Not sure what this means exactly but I also do not see why any of the
existing RFCs breaks this.

   o  an ability to express an instance of the structure consisting of
      models that have been validated to work together (i.e., with
      information about sources of the models, their versions, etc.), so
      that operators can easily identify a set of models that is known
      to be mutually consistent

Not sure what this means exactly but YANG modules published by the
IETF are supposed to work together. YANG 1.1 has even clearer rules
what imports mean etc.

Bottom line is that I do not get out of these bullets what is _broken_
with the existing RFCs. I like to see text of the sort

  - RFC 7223 is broken because ...
  - RFC 7277 is broken because ...
  [...]

This text is not in section 1.1 as far as I can tell.

Bottom line is that I do not understand why /interfaces is broken such
that this needs to be redone while /device/interfaces is golden. What do
we do if in two years some group of people find /device/network/interfaces
a brilliant idea?

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 1 Aug 2015 11:05:50 -0700

> 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.

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)

Thanks,
> Acee
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 03 Aug 2015 15:43:09 +0200

> This is why we have /interfaces. Interface related stuff goes here.

But it is only suitable for a single device with its set of
interfaces. So the ietf-interfaces module isn't broken but doesn't allow
for typical generalizations, e.g. a device comprising a number of
virtual devices, each with its own set of interfaces.

Lada

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

---

From: t.petch <[email-masked]>
Date: Mon, 3 Aug 2015 15:48:20 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Acee Lindem (acee)" <[email-masked]>
Cc: "NETMOD Working Group" <[email-masked]>
Sent: Saturday, August 01, 2015 7:05 PM
Subject: Re: [netmod] Y34
On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <[email-masked]>
wrote:

> Hi Juergen,
>
> On 8/1/15, 2:51 AM,  [email-masked]> wrote:
>

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.

Tom Petch

Thanks,
Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Aug 2015 08:10:14 -0700

> 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.

Andy

---

From: t.petch <[email-masked]>
Date: Mon, 3 Aug 2015 17:01:50 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "NETMOD Working Group" <[email-masked]>
Sent: Monday, August 03, 2015 4:10 PM

On Mon, Aug 3, 2015 at 7:48 AM, t.petch <[email-masked]> wrote:

> From: "Andy Bierman" [email-masked]

<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

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!

Tom Petch

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 3 Aug 2015 09:17:33 -0700

> 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.

Andy

---

From: t.petch <[email-masked]>
Date: Tue, 4 Aug 2015 10:34:55 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>
Sent: Monday, August 03, 2015 5:17 PM

<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.

 Tom Petch

Andy

> > to the real location of the resource. (like 301 Moved Permanently)

** 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.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Aug 2015 09:16:24 -0700

> 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.

 Tom Petch

Andy

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Sat, 8 Aug 2015 11:10:15 +0000

Andy,

I agree that there is a need for organization of models, but I don’t have a firm position on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model or draft-bierman-netmod-yang-package. But we absolutely need *something* to help end-users of the models comprehend the overall structure of models, their relationship and how to use them.

Cheers,

Einar

On Aug 4, 2015, at 5:16 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Aug 4, 2015 at 2:34 AM, t.petch <[email-masked]<mailto:[email-masked]>> wrote:
----- Original Message -----
From: "Andy Bierman" <[email-masked]<mailto:[email-masked]>>
To: "t.petch" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 03, 2015 5:17 PM

> From: "Andy Bierman" <[email-masked]<mailto:[email-masked]>>
> To: "t.petch" <[email-masked]<mailto:[email-masked]>>
> > From: "Andy Bierman" [email-masked]<mailto:[email-masked]>
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
> >
>>> On 8/1/15, 2:51 AM,  [email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Section 1.1 in
>>>

<tp>

Andy

 Tom Petch

Andy

Andy

** Solution Y34-02

  For example:

    #+BEGIN_EXAMPLE
    anydata data;
    #+END_EXAMPLE

** Solution Y34-05

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Aug 2015 09:21:10 +0200

> 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

---

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 10 Aug 2015 09:46:39 +0100

And it is not just end users who need help to better understand YANG
models and how to use them. For those still on the edge, looking to
finally take the plunge and use NETCONF/YANG to configure their
devices, help is also required to determine how best to structure
their YANG models, make use of the existing ones, etc. For those who
have "grown up" with the developments in NETCONF and YANG, much of
this is probably second nature. But coming to it cold (in the sense of
compiling/writing a first set of YANG models for a device; I've been
following the netconf/netmod WGs for 3+ years), it still feels very
much like a dark art! It is not just the individual modules, it is how
to put them together to best manage a device (let alone a system).
Jonathan

----- Original Message -----
From: "Einar Nilsen-Nygaard (einarnn)" 
To:"Andy Bierman" 
Cc:"NETMOD Working Group" 
Sent:Sat, 8 Aug 2015 11:10:15 +0000
Subject:Re: [netmod] Y34 - root node

 Andy, 
 I agree that there is a need for organization of models, but I
don’t have a firm position
on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model
or draft-bierman-netmod-yang-package. But we absolutely need
*something* to help end-users of the models comprehend the overall
structure of models, their relationship and how to use them. 
 Cheers, 
 Einar 
  On Aug 4, 2015, at 5:16 PM, Andy Bierman  wrote: 

On Tue, Aug 4, 2015 at 2:34 AM, t.petch   wrote:
 ----- Original Message -----
 From: "Andy Bierman" 
 To: "t.petch" 
 Sent: Monday, August 03, 2015 5:17 PM

 > From: "Andy Bierman" 
 > To: "t.petch" 
 > > From: "Andy Bierman" [email-masked] [7]
 > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
 > >
 >>> On 8/1/15, 2:51 AM,  [email-masked] [9]>
[10]
 >>> lists the goals of a generic model structure that will
accommodate
 >> most
[11]

 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.

 YANG models and wondering how a user will ever get a coherent picture
of

 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  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/
[12]

 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. 

   Tom Petch

 Andy    Andy

 ** Solution Y34-02

   For example:

     #+BEGIN_EXAMPLE
     anydata data;
     #+END_EXAMPLE

 ** Solution Y34-05

    - 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.

[email-masked] [13]

Links:
------
[1] mailto:[email-masked]
[2] mailto:[email-masked]
[3] mailto:[email-masked]
[4] mailto:[email-masked]
[5] mailto:[email-masked]
[6] mailto:[email-masked]
[7] mailto:[email-masked]
[8] mailto:[email-masked]
[9] mailto:[email-masked]
[10]
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
[11]
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
[12]
http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
[13] mailto:[email-masked]

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Mon, 10 Aug 2015 09:29:50 +0000

As someone sharing responsibilities for guiding a number of development teams both defining new models and implementing to some already defined models in this area, I can only agree with this addition to what I said earlier.

Cheers,

Einar

On Aug 10, 2015, at 9:46 AM, Jonathan Hansford <[email-masked]<mailto:[email-masked]>> wrote:

 And it is not just end users who need help to better understand YANG models and how to use them. For those still on the edge, looking to finally take the plunge and use NETCONF/YANG to configure their devices, help is also required to determine how best to structure their YANG models, make use of the existing ones, etc. For those who have "grown up" with the developments in NETCONF and YANG, much of this is probably second nature. But coming to it cold (in the sense of compiling/writing a first set of YANG models for a device; I've been following the netconf/netmod WGs for 3+ years), it still feels very much like a dark art! It is not just the individual modules, it is how to put them together to best manage a device (let alone a system).

Jonathan

----- Original Message -----
From:
"Einar Nilsen-Nygaard (einarnn)" <[email-masked]<mailto:[email-masked]>>

To:
"Andy Bierman" <[email-masked]<mailto:[email-masked]>>
Cc:
"NETMOD Working Group" <[email-masked]<mailto:[email-masked]>>
Sent:
Sat, 8 Aug 2015 11:10:15 +0000
Subject:
Re: [netmod] Y34 - root node

Andy,

Cheers,

Einar

----- Original Message -----
From: "Andy Bierman" <[email-masked]<mailto:[email-masked]>>
To: "t.petch" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 03, 2015 5:17 PM

> From: "Andy Bierman" <andy@yumaworkscom<mailto:[email-masked]>>
> these nodes is the document root
>

<tp>

Andy

I guess it is up to client tools to do that

 Tom Petch

Andy

Andy

** Solution Y34-02

  For example:

    #+BEGIN_EXAMPLE
    anydata data;
    #+END_EXAMPLE

** Solution Y34-05

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2015 09:09:43 -0700

On Mon, Aug 10, 2015 at 1:46 AM, Jonathan Hansford <[email-masked]>
wrote:

> models and how to use them. For those still on the edge, looking to finally
> take the plunge and use NETCONF/YANG to configure their devices, help is
> also required to determine how best to structure their YANG models, make
> use of the existing ones, etc. For those who have "grown up" with the
> developments in NETCONF and YANG, much of this is probably second nature.
> But coming to it cold (in the sense of compiling/writing a first set of
> YANG models for a device; I've been following the netconf/netmod WGs for 3+
> years), it still feels very much like a dark art! It is not just the
> individual modules, it is how to put them together to best manage a device
> (let alone a system).
>
>
IMO you are describing a different problem.
Certainly YANG authors need to know how to use YANG most effectively.

A separate problem is the ease of use of YANG module implementations
within NETCONF or RESTCONF servers by operators.

The current answer is (a) proprietary tool magic or (b) read every single
YANG module very carefully and then all the vendor documentation.
Then study the server module advertisements to plug in all the features,
revisions, and deviations.

The "resource directory" approach and YANG package approach are
complimentary.  It is useful to know that a <get> on /services/routing
will return the location of routing data.  It is also useful to know in
advance
what modules are used for routing in each server.

The location of actual resources should not be hard-wired and brittle.
We should learn from HTTP how to manage resources without hard-wiring
the paths to resources.

Andy

> "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
>
> To:
> "Andy Bierman" <[email-masked]>
> Cc:
> "NETMOD Working Group" <[email-masked]>
> Sent:
> I agree that there is a need for organization of models, but I don’t have
> a firm position
> or draft-bierman-netmod-yang-package. But we absolutely need *something* to
> help end-users of the models comprehend the overall structure of models,
> their relationship and how to use them.
>
> Cheers,
>
> Einar
>
> On Aug 4, 2015, at 5:16 PM, Andy Bierman <[email-masked]> wrote:
>
>
>
>> > From: "Andy Bierman" <andy@yumaworkscom <[email-masked]>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Aug 2015 19:34:38 +0000

I think there is agreement that there is a problem. The YANG Routing Design Team is  addressing this with https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt  (which has evolved from https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). In essence, a place for everything and everything in its place. However, there are those who feel that can’t mandate a single model structure for network devices and we need mechanisms to manage multiple models but allow for different device structure (e.g., https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).  I hope we can agree on an approach in the coming interim meetings.

Thanks,
Acee

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of "Einar Nilsen-Nygaard (einarnn)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford <[email-masked]<mailto:[email-masked]>>
Cc: NETMOD Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Y34 - root node

Cheers,

Einar

Jonathan

----- Original Message -----
From:

To:

Andy,

Cheers,

Einar

----- Original Message -----
From: "Andy Bierman" <[email-masked]<mailto:[email-masked]>>
To: "t.petch" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 03, 2015 5:17 PM

<tp>

Andy

 Tom Petch

Andy

Andy

** Solution Y34-02

  For example:

    #+BEGIN_EXAMPLE
    anydata data;
    #+END_EXAMPLE

** Solution Y34-05

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2015 13:15:12 -0700

On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) <[email-masked]> wrote:

> I think there is agreement that there is a problem. The YANG Routing
> Design Team is  addressing this with
> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt  (which
> has evolved from
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt).
> In essence, a place for everything and everything in its place. However,
> there are those who feel that can’t mandate a single model structure for
> network devices and we need mechanisms to manage multiple models but allow
> for different device structure (e.g.,
> https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).  I
> hope we can agree on an approach in the coming interim meetings.
>
>
Do you expect "everything in its place" to apply to all other SDOs and
all vendor modules? Or do you expect just the IETF routing modules
to follow this subtree hierarchy? If the former, does this mean the
YANG Routing Design Team is the "YANG data placement authority"
or all YANG modules that ever get written? How long should
it take for all other SDOs and vendors to redo all their existing
modules to re-root them in their assigned place in the data tree?

IMO is is not a good idea to rely on rigid data node placement,
and a single data placement authority. It is better and use meta-data
built from the YANG modules (or YANG packages) instead.

The reason Linux uses packages to install/update functionality
is because managing 8000 packages is hard enough.
Managing 247,000 individual files would be insane.
The actual location of files is quite configurable and different
across distros. We could learn something from the last decade
of Linux package management, and try to apply it to YANG.

Thanks,

Andy

>
>
>
> From: netmod <[email-masked]> on behalf of "Einar Nilsen-Nygaard
> (einarnn)" <[email-masked]>
> To: Jonathan Hansford <[email-masked]>
> Cc: NETMOD Working Group <[email-masked]>
> As someone sharing responsibilities for guiding a number of development
> teams both defining new models and implementing to some already defined
> models in this area, I can only agree with this addition to what I said
> earlier.
>
> Cheers,
>
> Einar
>
> On Aug 10, 2015, at 9:46 AM, Jonathan Hansford <[email-masked]>
> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 10 Aug 2015 21:28:34 +0000

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 10, 2015 at 4:15 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]<mailto:[email-masked]>>, Jonathan Hansford <[email-masked]<mailto:[email-masked]>>, NETMOD Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Y34 - root node

On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
I think there is agreement that there is a problem. The YANG Routing Design Team is  addressing this with https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt  (which has evolved from https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). In essence, a place for everything and everything in its place. However, there are those who feel that can’t mandate a single model structure for network devices and we need mechanisms to manage multiple models but allow for different device structure (e.g., https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).  I hope we can agree on an approach in the coming interim meetings.

I’d expect the final document to be a product of the netmod WG and, consequently, have wide review and approval. We are considering some changes to specify an identify for a class of data model rather than trying to specify specific models.

As for other SDOs and their YANG models, we can suggest placement but we really can even force them to use our building blocks.

I guess we’re going to have to see the programming model for this. Fixed paths do provide a clean programming model.

I wil give your draft a closer read.

Thanks,
Acee

Thanks,
Acee

Andy

Cheers,

Einar

Jonathan

----- Original Message -----
From:

To:

Andy,

Cheers,

Einar

----- Original Message -----
From: "Andy Bierman" <[email-masked]<mailto:[email-masked]>>
To: "t.petch" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 03, 2015 5:17 PM

<tp>

Andy

 Tom Petch

Andy

Andy

** Solution Y34-02

  For example:

    #+BEGIN_EXAMPLE
    anydata data;
    #+END_EXAMPLE

** Solution Y34-05

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Aug 2015 09:38:34 +0200

> On 10 Aug 2015, at 22:15, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

That’s an interesting idea, could a YANG package also specify, e.g. that the root node for the package is X/Y/Z? This could solve some use cases for relocatability, and it would also be relatively easy to modify all absolute XPath expressions inside the package.

Lada

> 
> 
> 
> 
> 
> Thanks,
> Acee  
> 
> 
> Andy
>  
> 
> 
> 
> From: netmod <[email-masked]> on behalf of "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
>> On Aug 10, 2015, at 9:46 AM, Jonathan Hansford <[email-masked]> wrote:
>> 
>> > From: "Andy Bierman" <andy@yumaworkscom>

---

From: t.petch <[email-masked]>
Date: Tue, 11 Aug 2015 11:38:13 +0100

----- Original Message -----
From: "Jonathan Hansford" <[email-masked]>
cc: "NETMOD Working Group" <[email-masked]>
Sent: Monday, August 10, 2015 9:46 AM

this is probably second nature.

<tp>

History suggests otherwise to me.  If you look at the evolution of
standard modules, such as routing and interfaces, that suggests that
those who have been immersed in YANG since NGO make several u-turns on
the way to where we now are, which may or may not be the end point.

You could also look at 6087 or 6087bis which are extensive but perhaps
not comprehensive.

Tom Petch

But coming to it cold (in the sense of

----- Original Message -----

 Andy,
on
draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-mod
el

 ----- Original Message -----
 From: "Andy Bierman"
 To: "t.petch"
 Sent: Monday, August 03, 2015 5:17 PM

accommodate

 Andy

  Tom Petch

 Andy   Andy

 ** Solution Y34-02

  For example:

  #+BEGIN_EXAMPLE
  anydata data;
  #+END_EXAMPLE

 ** Solution Y34-05

Links:
------

------------------------------------------------------------------------
--------

---

From: Robert Wilton <[email-masked]>
Date: Tue, 18 Aug 2015 17:59:31 +0100

>> built from the YANG modules (or YANG packages) instead.
I think that having fixed paths may end up being too restrictive.

> That’s an interesting idea, could a YANG package also specify, e.g. that the root node for the package is X/Y/Z? This could solve some use cases for relocatability, and it would also be relatively…
If someone wants to builds a YANG controller node that is managing the 
configuration for a network of devices then wouldn't they want a 
particular device's interface configuration to be located somewhere like 
/network/device/<device-name>/interfaces/interface? Ideally, they would 
be able to use the same YANG definitions that are defined for 
/interfaces/ but root them relative to /network/device/<device-name>/.

Having YANG packages being able to control the relative paths of the 
imported YANG modules would possibly allow for more flexibility in how 
YANG modules fit together, and also give a more pragmatic way for how 
these could be changed/upgraded in future if necessary.

Cheers,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Aug 2015 10:22:57 -0700

On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton <[email-masked]> wrote:

>>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt
>>> (which has evolved from

This is how languages like SMIv2 and YANG work.
A conceptual object is given a permanent "home" within the tree of object
identifiers.
Moving data is very expensive, since any clients working with the old data
will break as soon as the data is moved.

 I am not convinced the IETF can or should come up with a set of containers
that covers every possible topic that can be modeled in YANG.
Even if such a lake could be brought to a boil, I have no confidence
that the hierarchy will be 100% stable.  It can certainly
never be 100% complete.  If the IETF thinks it's a good idea
to obsolete all YANG RFCs and start over now, who is to say
the IETF won't do that again every few years?

>>> That’s an interesting idea, could a YANG package also specify, e.g. that
>> the root node for the package is X/Y/Z? This could solve some use cases for
>> relocatability, and it would also be relatively easy to modify all absolute
>> XPath expressions inside the package.
>>
> configuration for a network of devices then wouldn't they want a particular
> device's interface configuration to be located somewhere like
> /network/device/<device-name>/interfaces/interface? Ideally, they would be
> able to use the same YANG definitions that are defined for /interfaces/ but
> root them relative to /network/device/<device-name>/.
>
>

Yes -- some of us (like Martin) have pointed this out many times.
The "device" container on an NE does not help at all wrt/
aggregation on a controller. "/device" or "/" work the same for this
purpose.

> imported YANG modules would possibly allow for more flexibility in how YANG
> modules fit together, and also give a more pragmatic way for how these
> could be changed/upgraded in future if necessary.
>
>

YANG packages provide a way to describe a set of modules.
They do not change the top-level data nodes of any objects.
This would be very complicated and not really worth it.

IMO the "tree of NP containers" should be a resource directory,
meaning it contains links to the real resources.  Kind of like an
index in a library.  They don't keep the contents of every book in the
index.
They keep the location of every book in the index.  The index is stable.
The resource location does not have to be stable.

Andy

>
>
>
>> Lada
>>
>>
>>>
>>>
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>> From: netmod <[email-masked]> on behalf of "Einar
>>> Nilsen-Nygaard (einarnn)" <[email-masked]>
>>>> I agree that there is a need for organization of models, but I don’t
>>>> have a firm position on
>>>> draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model
>>>>>> 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
>>>>>> (augments, constraints) and so must be somewhere and must be
>>>>>>
>>>>> relatively
>>>>>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 19 Aug 2015 11:38:39 +0100

On 18/08/2015 18:22, Andy Bierman wrote:
>
>
> On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>             On 10 Aug 2015, at 22:15, Andy Bierman <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>
>
>             On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee)
>             <[email-masked] <mailto:[email-masked]>> wrote:
>             I think there is agreement that there is a problem. The
>             YANG Routing Design Team is  addressing this with
>             In essence, a place for everything and everything in its
>             place. However, there are those who feel that can’t
>             mandate a single model structure for network devices and
>             we need mechanisms to manage multiple models but allow for
>             different device structure (e.g.,
>             https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).
>             I hope we can agree on an approach in the coming interim
>             meetings.
>
>
> A conceptual object is given a permanent "home" within the tree of 
> object identifiers.

I mostly agree, but having some more structure/advice as to where to 
place YANG modules may be helpful.  I'm thinking more along the lines of 
broad categories rather than precise locations.

E.g. I had suggested that it might be good if the Diffserv QoS YANG 
model was located in some slightly more abstract QoS containers/choices 
(e.g. for queuing/shaping/policying/etc).

Mainly my reasoning for this was the observation that vendor specific 
extensions would probably fit better augmenting generic QoS containers 
rather than a DiffServ specific QoS model (e.g. if they were adding L2 
specific QoS features which wouldn't sit cleanly on top of a specific L3 
QoS model).  However, I think that Norman Finn also mentioned a 
requirement from Deterministic Networking where it may be necessary to 
interact with some abstract QoS parameters without having to know the 
precise details of the underlying QoS model.

One other observation is that if we do end up with some more hierarchy 
then the "can't augment with mandatory node" issue may become a much 
more widespread issue.  Today, top level models can introduce mandatory 
nodes, but if they were all augmentations of an existing container they 
would not be able to (without a P-container).

> the IETF won't do that again every few years?

My perception is that YANG models and how to fit them together are still 
somewhat in flux.  There are lots of drafts defining YANG models were 
folks (myself included) are trying to figure out how these models should 
all fit together, but relatively few published RFCs.  So, personally I 
think that there is still a potential opportunity to add some more 
structure at this time if the desire is strong enough.  But I'm new to 
IETF, and hence perhaps this is just my naivety of the IETF processes.  
Three years down the line and I doubt that will be the case - there will 
be too much inertia, and unless it is very broken it won't get changed.

>         That’s an interesting idea, could a YANG package also specify,
>         e.g. that the root node for the package is X/Y/Z? This could
>         solve some use cases for relocatability, and it would also be
>         relatively easy to modify all absolute XPath expressions
>         inside the package.
>
>     If someone wants to builds a YANG controller node that is managing
>     the configuration for a network of devices then wouldn't they want
>     a particular device's interface configuration to be located
>     somewhere like /network/device/<device-name>/interfaces/interface?
>     Ideally, they would be able to use the same YANG definitions that
>     are defined for /interfaces/ but root them relative to
>     /network/device/<device-name>/.
>
>
>
>     Having YANG packages being able to control the relative paths of
>     the imported YANG modules would possibly allow for more
>     flexibility in how YANG modules fit together, and also give a more
>     pragmatic way for how these could be changed/upgraded in future if
>     necessary.
>
>
>
What would the real resource location for 
"/network/device/<device-name>/interfaces/interface" be?  If the 
concrete location for all interfaces (regardless of device) was the flat 
list /interfaces/ then you would get clashes between the names of the 
interfaces on different devices.  Also, what if someone wanted two 
separate lists of interfaces in two separate parts of the resource 
hierarchy.  Would that be feasible?

Thanks,
Rob

>
>
>     Cheers,
>     Rob
>
>
> Andy
>
>
>
>
>         Lada
>
>
>
>
>
>             Thanks,
>             Acee
>
>
>             Andy
>
>
>
>             From: netmod <[email-masked]
>             <mailto:[email-masked]>> on behalf of "Einar
>             Nilsen-Nygaard (einarnn)" <[email-masked]
>             <mailto:[email-masked]>>
>             As someone sharing responsibilities for guiding a number
>             of development teams both defining new models and
>             implementing to some already defined models in this area,
>             I can only agree with this addition to what I said earlier.
>
>             Cheers,
>
>             Einar
>
>                 On Aug 10, 2015, at 9:46 AM, Jonathan Hansford
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                   And it is not just end users who need help to better
>                 understand YANG models and how to use them. For those
>                 still on the edge, looking to finally take the plunge
>                 and use NETCONF/YANG to configure their devices, help
>                 is also required to determine how best to structure
>                 their YANG models, make use of the existing ones, etc.
>                 For those who have "grown up" with the developments in
>                 NETCONF and YANG, much of this is probably second
>                 nature. But coming to it cold (in the sense of
>                 compiling/writing a first set of YANG models for a
>                 device; I've been following the netconf/netmod WGs for
>                 3+ years), it still feels very much like a dark art!
>                 It is not just the individual modules, it is how to
>                 put them together to best manage a device (let alone a
>                 system).
>
>                 Jonathan
>
>
>
>                 I agree that there is a need for organization of
>                 models, but I don’t have a firm position on
>                 or draft-bierman-netmod-yang-package. But we
>                 absolutely need *something* to help end-users of the
>                 models comprehend the overall structure of models,
>                 On Aug 4, 2015, at 5:16 PM, Andy Bierman
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>                 On Tue, Aug 4, 2015 at 2:34 AM, t.petch
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>                         <mailto:[email-masked]>
>                         On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem
>                         (acee) <[email-masked] <mailto:[email-masked]>>
>
>                             On 8/1/15, 2:51 AM,
>                             [email-masked]
>                             <mailto:[email-masked]>>
>                             wrote:
>
>                             Section 1.1 in
>
>                 [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Aug 2015 13:25:55 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> place YANG modules may be helpful.  I'm thinking more along the lines
> of broad categories rather than precise locations.

+1

> > aggregation on a controller. "/device" or "/" work the same for this

Actually, I would argue that / works better.  On the controller, you
probably have a list of devices you control (this is how our NCS
works, and how ODL works (I have been told)):

  container devices {
    list device {
      key name;
      // meta-info about the device goes here, things like
      // ip-address, port, auth info...
      container data {
        // all models supported by the devices are "mounted" here
      }
    }
  }

So on the controller, the path to interface "eth0" on device "foo"
would be:

  /devices/device[name='foo']/data/interfaces/interface[name='eth0']

if we also have a top-level "/device" container we'd have:

  /devices/device[name='foo']/data/device/interfaces/interface[name='eth0']

> "/network/device/<device-name>/interfaces/interface" be?

I don't think there is such a thing as a "real" location.  The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:

  /domains/domain[name='bar']/devices/device[name='foo']/data
    /interfaces/interface[name='eth0']

Currently we have a proprietary way of "relocating" YANG modules, and
ODL has its "mount", and I think Andy has some other mechanism.  Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Aug 2015 14:55:52 +0200

> On 19 Aug 2015, at 13:25, Martin Bjorklund <[email-masked]> wrote:
> 

+1

Lada

---

From: Robert Wilton <[email-masked]>
Date: Wed, 19 Aug 2015 15:39:17 +0100

> standardize the list of devices in a controller model.
Yes, I agree.

I was also questioning whether relocating YANG modules is something that 
YANG packages could/should be concerned with.

There is also draft-clemm-netmod-mount-00 which seems to be concerned 
with mounting external datastores in part of the data tree that may also 
be worth considering.

Thanks,
Rob

> .

---

From: t.petch <[email-masked]>
Date: Wed, 19 Aug 2015 17:24:41 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 19, 2015 12:25 PM
> > > Moving data is very expensive, since any clients working with the
old
> > > data

Martin

If I were able to choose someone to ask for advice on this question,
well, your name would be joint top of my list.  If you are not going to
write it, then who is?

The current model is a flat architecture of hundreds (or thousands) of
modules each with their own top level nodes, namespace, namespace name,
prefix etc.  (This is quite different to SMI with its hierarchy but that
probably is only significant to those who have spent 20 years with SMI).

So, is this flat architecture a problem?  Does it matter that we have
hundreds (or thousands) of top level nodes?  I know that top level nodes
are different w.r.t the rules of YANG but cannot foresee whether or not
that is an issue for model writers or model users because I cannot get
my mind around just what the rules are in this regard?

Equally, is it a problem to have hundreds (or thousands) of prefixes? or
namespaces? or ...

And what else is there that having a lot of might be an issue?

I see the YANG architecture as reflecting the IETF 'architecture' of
hundreds of working groups loosely federated, sometimes collaborating,
mostly not, and so is the right way to develop YANG modules.  But are
there technical dangers lurking there that in a few years time we will
wish we had taken more notice of.

Tom Petch

> > >     somewhere like
/network/device/<device-name>/interfaces/interface?
> if we also have a top-level "/device" container we'd have:
/devices/device[name='foo']/data/device/interfaces/interface[name='eth0'
]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Aug 2015 09:55:22 -0700

> my mind around just what the rules are in this regard?

But this is not what we have.
Many times a YANG module augments another on (such as ietf-interfaces).

As for 100s maybe 1000s...;

Here is the datastore contents that the IETF has defined so far:
[not sure if I am leaving out other WGs]

    Yr        RFC      root                     comments

   2008    5277     /netconf               Notification streams (XSD, no
YANG at all)
   2010    6022     /netconf-state      NETCONF monitoring
   2012    6536     /nacm                  NETCONF access control
   2012    6728     /ipfix                    IPFIX and PSAMP configuration
   2014    7223     /interfaces            Interface management
                            /interfaces-state
   2014   7277    augment /interfaces/interface   IP management
   2014   7317     /system                   Host system management
   2014   7407     /snmp                     SNMP configuration

Maybe 1000s, maybe 8.

I would hardly say that this represents a problem that is out of control.
I also would not call 7 RFCs in 5 years with YANG data in them as much
progress.
At this rate it will take 150 years to fill in the tree of NP containers
will real modules.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Aug 2015 21:39:05 -0700

+1

We just need to standardize a "docroot within a docroot".
This is not relocation of subtrees within the datastore, this is just
mounting
a datastore somewhere within a parent datastore.

In YANG validation terms, you simply adjust the docroot to the nested mount
point,
and the replicated datastore can be used as if it were stand-alone.
This would allow any sort of encapsulation of datastores and not add any
data model complexity to devices which do not have virtual servers
(most of them).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Aug 2015 10:15:33 +0200 (CEST)

> data model complexity to devices which do not have virtual servers

Compared to the mount draft, I would like to decouple the schema
information from the instance population mechanism.  I.e., I'd like a
mechanism that simply defines the schema, not necessarily how the data
is populated (in the mount draft data was fetched from a remote
server, but IMO that is just one of several use cases).

I can think of two ways to do this.

1)  Your "ycx:root" statement.  This is open-ended, so we could do:

      list logical-element {
        key name;
        leaf name { ... }
        yang-root true;
      }

    From a schema perspective, any top-level node from any data model
    could be used within the logical-element list.

2)  Cherry-picking:

      list logical-element {
        key name;
        leaf name { ... }
        mount if:interfaces;
        mount sys:system;
        ...
      }

Or maybe combine them into one "mount" statement:

   mount *;  // allow any top-level node
   mount sys:system; // allow this specific top-level node

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 20 Aug 2015 11:10:13 +0200

Andy Bierman <[email-masked]> writes:

> We just need to standardize a "docroot within a docroot".  This is not
> relocation of subtrees within the datastore, this is just mounting a
> datastore somewhere within a parent datastore.

The current definition of datastore is too general, so I don't know what
datastore inside datastore means. What's clear is that a single module
cannot just be mounted anywhere. For example, if ietf-interfaces is
mounted under /device and ietf-ip straight under /, then I don't see how
references and XPath expressions could be reliably modified to work as
expected.

That's why I think only self-contained packages can be mounted, and
inside them all references can be prepended with the mount root.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Fri, 21 Aug 2015 13:07:40 +0100

Hi Martin,

> server, but IMO that is just one of several use cases).
Yes, I agree that these could/should be decoupled.  Although I note that 
the mount draft does also allow for local mounts, although this does not 
seem to be intended to be the mainline case.

>      could be used within the logical-element list.
I think that that it makes the overall schema more useful if it 
explicitly states what schema is used for the mounted nodes, although 
possibly a wildcard mount could still be allowed.

I wasn't quite sure how it would work if you wanted to mount a schema 
that has augmentations.  Would you have to list all supported 
augmentations in the mount point as well?  Otherwise you wouldn't know 
what the full schema is.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 21 Aug 2015 15:01:58 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> Yes, I agree that these could/should be decoupled.  Although I note
> that the mount draft does also allow for local mounts, although this
> does not seem to be intended to be the mainline case.
> 
> >

My idea is that you mount the top-level node, and that means that
everything below it is "copied" into the new location.  I.e.,
augmentations to the subtree are also copied.  So you would not mount
any augmentations (that's why the syntax is mount <top-level-node>).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 21 Aug 2015 15:45:07 +0200

> On 21 Aug 2015, at 15:01, Martin Bjorklund <[email-masked]> wrote:
> 

But what about normal modules that refer to nodes in the mounted module? Their XPath expressions and leafrefs would be incorrect.
I think they must be mounted to the same root, too.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Aug 2015 07:27:39 -0700

> any augmentations (that's why the syntax is mount <top-level-node>).
I am only interested in (1) ncx:root approach because this actually works.

Cherry-picking does not work well because
   (a) subtrees are allowed to have constraints on data outside that subtree
   (b) YANG XPath cannot be safely relocated up or down (i.e., move
/interfaces to
   /device/interfaces or move /foo/bar/baz to /foo2/baz

/martin

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 23 Aug 2015 19:04:15 +0200

> probably is only significant to those who have spent 20 years with SMI).

This is most likely a wrong perception. There are basically only two
locations where SNMP modules are registered in the IETF: under mib-2
and under transmission (yes there are a few exceptions but overall in
number they do not matter). There are close to 240 MIB modules below
mib-2 and about 50 MIB modules below transmission.

RFC 4181:

   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the
     mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863] it is customary to use
     an IANA-assigned value under transmission [RFC2578].  In the past,
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Aug 2015 17:25:36 +0000

I like the idea of relocatable modules.  It is almost to say everything defined by the IETF should be a grouping, allowing others to assemble the pieces as they see fit.  I do not think it makes sense for IETF to define an uber structure, especially using a language mandating forever backwards compatibility...

How to support logical/virtual systems is a bigger discussion.   Certainly there is a huge data model overlap between the host system and the logical systems, but some data may only exist in the host system and some data may only exist in a logical system.  Making things more interesting, some data in the host system (e.g., an interface) can be exported to a logical system as a read-only value.   The way I solved this in another life was using conditional enablement [1] on a shared data model to indicate the applicability of nodes in a context.

[1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00

Kent, as a contributor

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Aug 2015 12:11:29 -0700

On Tue, Aug 25, 2015 at 10:25 AM, Kent Watsen <[email-masked]> wrote:

>
> I like the idea of relocatable modules.  It is almost to say everything
> defined by the IETF should be a grouping, allowing others to assemble the
> pieces as they see fit.  I do not think it makes sense for IETF to define
> an uber structure, especially using a language mandating forever backwards
> compatibility...
>
>
YANG groupings are not really relocatable.
If any object has a YANG constraint (must/when/path) that is outside the
grouping, then the grouping is not really relocatable.
Only groupings that have no "external references" can be relocated,
and this assumes the YANG is written using only relative roots, not
absolute paths.

Andy

How to support logical/virtual systems is a bigger discussion.   Certainly
> there is a huge data model overlap between the host system and the logical
> systems, but some data may only exist in the host system and some data may
> only exist in a logical system.  Making things more interesting, some data
> in the host system (e.g., an interface) can be exported to a logical system
> as a read-only value.   The way I solved this in another life was using
> conditional enablement [1] on a shared data model to indicate the
> applicability of nodes in a context.
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 25 Aug 2015 22:51:07 +0000

From: Andy Bierman,  Friday, August 21, 2015 10:28 AM

<snip>
> >>> standardize the list of devices in a controller model.

It seems there are many places where mount is being used effectively.  I am all for some standard syntax.

> does not seem to be intended to be the mainline case.

The mount draft was indeed driven by OpenDaylight's use cases.  In ODL, mount is used for local YANG representation of remote device information. 

Based on this I believe a generalized mount syntax should not mandate that the target must be local and cannot be remote.  Nor should a generalized mount syntax itself restrict whether the target node contain schema or instance info.   There are many ways beyond the syntax if an implementation has no desire for this.

Eric

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 26 Aug 2015 07:17:22 -0400

> On Aug 25, 2015:1:25 PM, at 1:25 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> I like the idea of relocatable modules.  It is almost to say everything defined by the IETF should be a grouping, allowing others to assemble the pieces as they see fit.  I do not think it makes sense for IETF to define an uber structure, especially using a language mandating forever backwards compatibility… 
	
	I personally think this is an important point not just for a list of the most recent incarnations of modules, but also as we (perhaps rapidly) iterate and rev modules going forward.  In particular, think about this within the context of the RFC model and what that implies going forward for model iteration.   Assembling pieces, including different revisions of models, is something we should think about.

	—tom

---

From: t.petch <[email-masked]>
Date: Wed, 26 Aug 2015 17:41:29 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Cc: <[email-masked]>; "Martin Bjorklund" <[email-masked]>;
<[email-masked]>
Sent: Sunday, August 23, 2015 6:04 PM

> mib-2 and about 50 MIB modules below transmission.

Juergen

I know what you mean, that the MIB module tree is somewhat fasciated,
but there is still one root, from which an obvious, absolute OID can be
used to identify uniquely any MIB module (or in some contexts a
relative one, relative to transmission or mib 2).  If SMI did have
constraints, then there would not be an issue of how to express them,
nor would there be any question of mounting a module elsewhere for
whatever
reason (which then creates problems for the references in the
constraints).

A flat sea of YANG modules is different; I haven't counted lately how
many
top level nodes I have seen but it is a lot and when I see people
wanting to
organise YANG modules into a tree, I wonder if they are trying to
recreate
an SMI-like tree and my reaction is that this is not SMI!

The flat sea of
YANG modules brings a different set of issues and I am unsure what they
are;
I understand what is involved with the references in constraints, I can
see that
there will be a lot of namespaces and prefixes and can speculate about
what
that will bring but what it means to have so many top level nodes, I do
not
know.

I believe that in a year or three we will be wishing we had paid more
attention
to this.

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2015 09:57:23 -0700

> I believe that in a year or three we will be wishing we had paid more

YANG uses XPath absolute-path expressions to identify data instances.
Each node in the tree has a QName (namespace + local-name).
There is zero ambiguity in an absolute path expression, so it
works whether there are 3 modules or 30,000 modules.
But if the path expression cannot change over time.

We do not need to place every new node at the top.
In fact, we don't, as the ietf-ip module proves.
We do need to pick a home for data and never change it -- ever.
Starting over with a data node means picking a new location for its home.

IMO the "logical view" injected into the model is the worst part.
This does not apply to very many implementations, and these
virtual devices are usually dealt with in the protocol, not the data model.
That way, different logical views can be derived, instead of imposing
a single logical model (with a uint8 index to cover all possible logical
instances).

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 26 Aug 2015 22:29:46 +0000

Coming late to the thread.

A couple of comments to add on to and/or respond to others:

- Mounting IMHO is a good way to address the requirement for various paths.  As has been been mentioned, this has been successfully used e.g. for Open Daylight and the use case of mounting / referring to information from remote devices in the context of one consolidated network inventory and topology model that is accessed by clients and applications on top of ODL.  

- The peer-mount draft was aimed at mounting subtrees from remote systems.  There is definitely also the possibility to generalize this for aliasing even within the same system (as discussed here).  However, as Eric points out there is no reason to restrict such a capability to the boundaries of a single system.  

- As Martin mentioned, clearly by allowing to mount you are decoupling schema information and instance population.  Regarding the issue of validation, this can be addressed by several ways.  In the mount draft, our answer has been that every piece of data has an authoritative owner - the server from which the data is mounted.  This is where validation and enforcing of integrity constraints needs to occur.   It is possible for an integrity constraints to refer to data that has been mounted, but the enforcement / validation is always the responsibility of the local "authoritative" server.  In other words, mounted information provides an additional, alternative view on data without replacing/substituting the original instance, and possibly restricting the types of operations that it can be subjected to (e.g. retrieval only).  

--- Alex  

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Friday, August 21, 2015 6:45 AM
To: Martin Björklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Y34 - root node

>>>>>>> A conceptual object is given a permanent "home" within the tree 
>>>>>>> of object identifiers.
>>>>>>> Moving data is very expensive, since any clients working with 
>>>>>>> the old data will break as soon as the data is moved.
>>>>>>> 
>>>>>>>  I am not convinced the IETF can or should come up with a set of  
>>>>>>> containers that covers every possible topic that can be modeled 
>>>>>>> in YANG.
>>>>>> I mostly agree, but having some more structure/advice as to where 
>>>>>> to place YANG modules may be helpful.  I'm thinking more along 
>>>>>> the lines of broad categories rather than precise locations.
>>>>> +1
>>>>> 
>>>>>>> aggregation on a controller. "/device" or "/" work the same for 
>>>>>>> this purpose.
>>>>> Actually, I would argue that / works better.  On the controller, 
>>>>> you probably have a list of devices you control (this is how our 
>>>>> NCS works, and how ODL works (I have been told)):
>>>>> 
>>>>>   container devices {
>>>>>     list device {
>>>>>       key name;
>>>>> I don't think there is such a thing as a "real" location.  The 
>>>>> path is scoped in the system you work with; in the controller it 
>>>>> might be as I illustrated above, in the device it starts with 
>>>>> /interfaces, but in a controller-of-controllers it might be:
>>>>> 
>>>>> Currently we have a proprietary way of "relocating" YANG modules, 
>>>>> and ODL has its "mount", and I think Andy has some other 
>>>>> mechanism.  Maybe the time has come to standardize how mount 
>>>>> works, and maybe then also standardize the list of devices in a controller model.
>>>>> 
>>>>> 
>>>> +1
>>>> 
>>>> This is not relocation of subtrees within the datastore, this is 
>>>> just mounting a datastore somewhere within a parent datastore.
>>>> 
>>>> In YANG validation terms, you simply adjust the docroot to the 
>>>> nested mount point, and the replicated datastore can be used as if 
>>>> it were stand-alone.
>>>> This would allow any sort of encapsulation of datastores and not 
>>>> add any data model complexity to devices which do not have virtual 
>>>> servers (most of them).
>>> information from the instance population mechanism.  I.e., I'd like 
>>> a mechanism that simply defines the schema, not necessarily how the 
>>> data is populated (in the mount draft data was fetched from a remote 
>> augmentations in the mount point as well?  Otherwise you wouldn't 
>> know what the full schema is.
> 

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Aug 2015 08:27:06 +0200 (CEST)

"Alexander Clemm (alex)" <[email-masked]> wrote:
> - As Martin mentioned, clearly by allowing to mount you are
> decoupling schema information and instance population.  Regarding
> the issue of validation, this can be addressed by several ways.

I think that the mount point effectively works as a 'chroot' for all
mounted data models in the mount point.  This means that if
ietf-interfaces and ietf-routing are mounted under
/devices/device/data, all XPath expressions and leafref paths and
instance-identifiers in these models are evaluated in a chrooted
environment where their '/' is set to
/device/device[name='...']/data.  This is how we implement validation
for such modules in our NCS (manager product).

In an implementation that actually does not store the data locally,
but fetches it from a remote device (like the original mount
proposal), it is fine to push also validation to the remote node.

[maybe mount is not a good name for this generalized thing; this term
might make you believe that the data has to be provided by some other
server.]

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Aug 2015 08:42:42 +0200

> reason (which then creates problems for the references in the

While SMIv2 does not have something like MUST and WHEN expressions, it
still does have references between model elements. Prime example:
ifTabel got augmented by ifXTable registered in a very different
location. It is a major mis-conception that the OID tree is relevant;
what is relevant are relationships between conceptual tables.

> A flat sea of YANG modules is different; I haven't counted lately
> how many top level nodes I have seen but it is a lot and when I see
> people wanting to organise YANG modules into a tree, I wonder if
> they are trying to recreate an SMI-like tree and my reaction is that
> this is not SMI!

There is no point in organizing them into a tree. There simply is no
universal forever stable tree. When SMIv2 started, people thought such
a tree would evolve and it was later recognized that this is an
illusion and we ended up registering almost everything under mib-2 or
transmission.

> The flat sea of YANG modules brings a different set of issues and I
> am unsure what they are;

This is main problem I have. What the heck is the problem we are trying
to fix?

> I understand what is involved with the references in constraints, I
> can see that there will be a lot of namespaces and prefixes and can
> speculate about what that will bring but what it means to have so
> many top level nodes, I do not know.

Having 200+ MIB modules registered below mib-2 has not been a problem
as far as I know.

/js

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2015 07:27:44 -0400

> This is main problem I have. What the heck is the problem we are trying

The first, but not only problem, is today's ~200 top level models
(looking at current RFCs and I-Ds) with little apparent organization or
inter-relationship.

Lou

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 05:23:34 -0700

> Having 200+ MIB modules registered below mib-2 has not been a problem

The only thing the same between SMIv2 and YANG here is age-old question
of how should we care about "dumb" tools that are not very schema-aware.

With YANG, the data related to "foo" can actually be located
under /some/path/to/foo.

I agree with you that for a programmatic interface, the location is not
at all important, but to a human typing URLs into a browser,
it will be important.

I don't see the 6 modules that have already been published so far in RFCs
as the problem.  I suggest focusing on the 194 modules that have not
been published.  Should the IETF spend a year or two debating the ONE TRUE
PERFECT uber-tree? 6 months?  How long will it take for all interested
vendors to agree where every little thing goes, before starting on any of
it.

Andy

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2015 08:59:44 -0400

On 8/27/2015 8:23 AM, Andy Bierman wrote:
> been published.

100% agree
>   Should the IETF spend a year or two debating the ONE TRUE
> PERFECT uber-tree? 6 months?
No, IMO we should take a stab at it and go with our best understanding
and consensus -- that is after all what the I*E*TF is all about.

> How long will it take for all interested
> vendors to agree where every little thing goes, before starting on any
> of it.
>

The DT's proposal seems to be a consensus starting point (from my DT and
individual perspective, based on *many* discussions with vendors and
users) in at least the routing area.  Outside the routing area, I've
heard three or four individual objections.  Not saying we have it right,
but just that we have a solid start.

Lou

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Thu, 27 Aug 2015 13:54:08 +0000

IMHO, there should a YANG Construct should allow modules to be reused within another module with a restriction of looping.

When the YANG modules organized at controller, or any manager, re use of grouping or a particular XPath mount makes life static in YANG. 

Br,
Ambika Prasad Tripathy (ambtripa)
-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, August 27, 2015 6:30 PM
To: Andy Bierman; Juergen Schoenwaelder; t. petch; Martin Bjorklund; [email-masked]
Subject: Re: [netmod] Y34 - root node

On 8/27/2015 8:23 AM, Andy Bierman wrote:
>
> I don't see the 6 modules that have already been published so far in 
> RFCs as the problem.  I suggest focusing on the 194 modules that have 
> not been published.

100% agree
>   Should the IETF spend a year or two debating the ONE TRUE PERFECT 
> uber-tree? 6 months?
No, IMO we should take a stab at it and go with our best understanding and consensus -- that is after all what the I*E*TF is all about.

> How long will it take for all interested vendors to agree where every 
> little thing goes, before starting on any of it.
>

Lou

---

From: t.petch <[email-masked]>
Date: Thu, 27 Aug 2015 17:42:00 +0100

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: "t. petch" <[email-masked]>; "Martin Bjorklund"
<[email-masked]>; <[email-masked]>
Sent: Thursday, August 27, 2015 12:27 PM

Lou

yes, but so what:-)

I do share Juergen's view here of what is the problem.  Earlier this
year, the focus was on presenting a coherent picture to the user and
Randy rightly pointed out that it took expert writers of NMS to bring
together data from mulitple modules to give the user a coherent display;
or it took expert writers of DDLs to produce modules that brought the
data together so that the writer of NMS have an easier task -  either
way, it needs experts and I do not see YANG being that different from
SMI in that regard.  Likely 'augments' will be used more so that YANG
will have more defined interrelationships in the DDL than SMI but not
enough to produce a coherent picture.

I do not see the benefit, in this or other regards, of placing YANG
modules in a tree, or in multiple trees.  What is the audience that will
benefit from that?

I do see the flat sea of modules as reflecting the way in which the IETF
works, in a loose federation, so that even within an Area, such as
Routing, you would not expect OSPF, say, to be au fait with MPLS, say;
so when they create their modules, they may not well dovetail as well as
they might but that is the way that the IETF is

Tom Petch

ps I have other concerns, but I have said enough about those lately so I
think about them some more

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 27 Aug 2015 22:22:21 +0000

Yes.  The one thing I would add is that validation of the mounted data can occur in its original path (the authoritative owner (in the distributed case)).  It should not be required to do this validation with the chrooted path, although that path can be used by other data nodes that refer to / have dependencies on the mounted data.  

Regarding naming, do you have an alternative suggestion?

Cheers
--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 11:27 PM
To: Alexander Clemm (alex) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Y34 - root node

"Alexander Clemm (alex)" <[email-masked]> wrote:
> - As Martin mentioned, clearly by allowing to mount you are decoupling 
> schema information and instance population.  Regarding the issue of 
> validation, this can be addressed by several ways.

I think that the mount point effectively works as a 'chroot' for all mounted data models in the mount point.  This means that if ietf-interfaces and ietf-routing are mounted under /devices/device/data, all XPath expressions and leafref paths and instance-identifiers in these models are evaluated in a chrooted environment where their '/' is set to /device/device[name='...']/data.  This is how we implement validation for such modules in our NCS (manager product).

In an implementation that actually does not store the data locally, but fetches it from a remote device (like the original mount proposal), it is fine to push also validation to the remote node.

[maybe mount is not a good name for this generalized thing; this term might make you believe that the data has to be provided by some other server.]

/martin

---

From: Robert Varga <[email-masked]>
Date: Fri, 28 Aug 2015 04:26:23 +0200

On 07/21/2015 09:44 AM, Juergen Schoenwaelder wrote:
> Lada, you can't simply 'mount' a data model into a different place.
> Think about paths in must or when expressions, or think about paths
> contraints in leafrefs etc

In ODL we already have a language extension which does this. 
Semantically it embeds the conceptual 'root' node into container/list 
item. That item becomes the logical root against which all expressions 
in the embedded models are evaluated against, e.g. it is its own little 
world, no constraints coming in or out of it. While incoming references 
could be done (by just crossing the embedding item), we have not found a 
use case for it yet.

This works rather well for providing a 'pass-through' function through a 
network controller down to individual devices: the devices themselves 
are represented as nodes in the topology model (exposed on the 
northbound) and a container holding the 'mount-point'. All operations in 
the mount-point space are mapped to NETCONF operations on the device 
(and hence it is the device itself who enforces constraints and 
referential integrity).

Bye,
Robert

---

From: Robert Varga <[email-masked]>
Date: Fri, 28 Aug 2015 04:34:52 +0200

On 07/27/2015 08:18 AM, Andy Bierman wrote:
> (1) Aggregation of datastores
>
> The simplest form is aggregation.
> It is possible to define a YANG container that is a conceptual
> document root, such that the set of child nodes matches the set
> of top-level YANG data nodes supported by the server.

I think a run-time facility to provide an actual list of valid models 
would be useful. Since the aggregation can be the result of aggregating 
various devices, the set of valid nodes may differ between root 
container instances.

Bye,
Robert

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Aug 2015 15:34:25 +0200

Hi Robert,
> On 28 Aug 2015, at 04:26, Robert Varga <[email-masked]> wrote:
> 
> In ODL we already have a language extension which does this. Semantically it embeds the conceptual 'root' node into container/list item. That item becomes the logical root against which all expressions in the embedded models are evaluated against, e.g. it is its own little world, no constraints coming in or out of it. While incoming references could be done (by just crossing the embedding item), we have not found a use case for it yet.

Yes, I think this could work. Two questions:

1. Is it possible to graft the same module multiple times in different places, perhaps in different revisions and with different features?

2. Can you identify a *set* of modules that are chrooted this way? For example, can you say you want to have a common root for ietf-interfaces, ietf-ip and ietf-system, rather than putting each module in its separate little world?

Thanks, Lada

> 
> This works rather well for providing a 'pass-through' function through a network controller down to individual devices: the devices themselves are represented as nodes in the topology model (exposed on the northbound) and a container holding the 'mount-point'. All operations in the mount-point space are mapped to NETCONF operations on the device (and hence it is the device itself who enforces constraints and referential integrity).
> 
> Bye,
> Robert
>

---

From: Robert Varga <[email-masked]>
Date: Fri, 28 Aug 2015 17:13:46 +0200

> 2. Can you identify a *set* of modules that are chrooted this way? For example, can you say you want to have a common root for ietf-interfaces, ietf-ip and ietf-system, rather than putting each mod…

I would say the answer to both questions should be yes, otherwise it 
would not work well in a heterogeneous environment and/or presence of 
inter-module constraints.

 From implementation perspective, we do not declare these in the model 
itself -- it acts only as a marker for the client to understand that it 
talks to a 'sub-device' and should look for a chrooted RFC6020 
/netconf-state subtree to see what is going on in a particular chroot 
instance.

Bye,
Robert