Re: [netmod] Y34

[Robert Varga]

On 08/28/2015 03:34 PM, Ladislav Lhotka wrote:

Hi Robert,

On 28 Aug 2015, at 04:26, Robert Varga  wrote:

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.

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?


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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Ladislav Lhotka]

Hi Robert,
> On 28 Aug 2015, at 04:26, Robert Varga  wrote:
> 
> 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.

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
> 

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Robert Varga]

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Robert Varga]

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Alexander Clemm (alex)]

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:m...@tail-f.com] 
Sent: Wednesday, August 26, 2015 11:27 PM
To: Alexander Clemm (alex) 
Cc: lho...@nic.cz; netmod@ietf.org
Subject: Re: [netmod] Y34 - root node

"Alexander Clemm (alex)"  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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[t . petch]

- Original Message -
From: "Lou Berger" 
To: "Juergen Schoenwaelder" 
Cc: "t. petch" ; "Martin Bjorklund"
; 
Sent: Thursday, August 27, 2015 12:27 PM
> On 08/27/2015 02:42 AM, Juergen Schoenwaelder wrote:
> >> 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?
> >
>
> 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

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

> Lou

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Ambika Prasad Tripathy (ambtripa)]

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:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Thursday, August 27, 2015 6:30 PM
To: Andy Bierman; Juergen Schoenwaelder; t. petch; Martin Bjorklund; 
netmod@ietf.org
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.
>

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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Lou Berger]

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

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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Andy Bierman]

On Wed, Aug 26, 2015 at 11:42 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Aug 26, 2015 at 05:41:29PM +0100, t. petch wrote:
> > - Original Message -
> > From: "Juergen Schoenwaelder" 
> > To: "t. petch" 
> > Cc: ; "Martin Bjorklund" ;
> > 
> > Sent: Sunday, August 23, 2015 6:04 PM
> >
> > > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote:
> > >
> > > > 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).
> > >
> > > 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.
> >
> > 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).
>
> 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.
>
>

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.



> /js
>
>
Andy


> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Lou Berger]

On 08/27/2015 02:42 AM, Juergen Schoenwaelder wrote:
>> 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?
> 

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Juergen Schoenwaelder]

On Wed, Aug 26, 2015 at 05:41:29PM +0100, t. petch wrote:
> - Original Message -
> From: "Juergen Schoenwaelder" 
> To: "t. petch" 
> Cc: ; "Martin Bjorklund" ;
> 
> Sent: Sunday, August 23, 2015 6:04 PM
> 
> > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote:
> >
> > > 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).
> >
> > 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.
> 
> 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).

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Martin Bjorklund]

"Alexander Clemm (alex)"  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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Alexander Clemm (alex)]

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:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Friday, August 21, 2015 6:45 AM
To: Martin Björklund 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y34 - root node


> On 21 Aug 2015, at 15:01, Martin Bjorklund  wrote:
> 
> Robert Wilton  wrote:
>> Hi Martin,
>> 
>> On 20/08/2015 09:15, Martin Bjorklund wrote:
>>> Andy Bierman  wrote:
>>>> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund 
>>>> wrote:
>>>> 
>>>>> Robert Wilton  wrote:
>>>>>> 
>>>>>> On 18/08/2015 18:22, Andy Bierman wrote:
>>>>>>> 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.
>>>>>> 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
>>>>> 
>>>>>>> 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//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//.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>> 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 su

Re: [netmod] Y34 - root node

[Andy Bierman]

On Wed, Aug 26, 2015 at 9:41 AM, t.petch  wrote:

> - Original Message -
> From: "Juergen Schoenwaelder" 
> To: "t. petch" 
> Cc: ; "Martin Bjorklund" ;
> 
> Sent: Sunday, August 23, 2015 6:04 PM
>
> > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote:
> >
> > > 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).
> >
> > 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.
>
> 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.
>
>

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







> Tom Petch
>

Andy


>
> > 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
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[t . petch]

- Original Message -
From: "Juergen Schoenwaelder" 
To: "t. petch" 
Cc: ; "Martin Bjorklund" ;

Sent: Sunday, August 23, 2015 6:04 PM

> On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote:
>
> > 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).
>
> 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.

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

> 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
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Nadeau Thomas]

> On Aug 25, 2015:1:25 PM, at 1:25 PM, Kent Watsen  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


> 
> 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
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Eric Voit (evoit)]

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


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

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

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

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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Andy Bierman]

On Tue, Aug 25, 2015 at 10:25 AM, Kent Watsen  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.
>
> [1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00
>
> Kent, as a contributor
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Kent Watsen]

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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Juergen Schoenwaelder]

On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote:

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

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Andy Bierman]

On Fri, Aug 21, 2015 at 6:01 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> > Hi Martin,
> >
> > On 20/08/2015 09:15, Martin Bjorklund wrote:
> > > Andy Bierman  wrote:
> > >> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund 
> > >> wrote:
> > >>
> > >>> Robert Wilton  wrote:
> > 
> >  On 18/08/2015 18:22, Andy Bierman wrote:
> > > 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.
> >  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
> > >>>
> > >  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//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//.
> > >
> > >
> > >
> > > 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.
> > >>> 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']
> > >>>
> >  What would the real resource location for
> >  "/network/device//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.
> > >>>
> > >>>
> > >> +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).
> > > 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).
> > 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.
> >
> > >
> > > 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 

Re: [netmod] Y34 - root node

[Ladislav Lhotka]

> On 21 Aug 2015, at 15:01, Martin Bjorklund  wrote:
> 
> Robert Wilton  wrote:
>> Hi Martin,
>> 
>> On 20/08/2015 09:15, Martin Bjorklund wrote:
>>> Andy Bierman  wrote:
 On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund 
 wrote:
 
> Robert Wilton  wrote:
>> 
>> On 18/08/2015 18:22, Andy Bierman wrote:
>>> 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.
>> 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
> 
>>> 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//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//.
>>> 
>>> 
>>> 
>>> 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.
> 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']
> 
>> What would the real resource location for
>> "/network/device//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.
> 
> 
 +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).
>>> 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).
>> 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.
>> 
>>> 
>>> 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:
>>> 
>>>  

Re: [netmod] Y34 - root node

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Martin,
> 
> On 20/08/2015 09:15, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> >> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund 
> >> wrote:
> >>
> >>> Robert Wilton  wrote:
> 
>  On 18/08/2015 18:22, Andy Bierman wrote:
> > 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.
>  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
> >>>
> >  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//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//.
> >
> >
> >
> > 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.
> >>> 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']
> >>>
>  What would the real resource location for
>  "/network/device//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.
> >>>
> >>>
> >> +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).
> > 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).
> 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.
> 
> >
> > 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;
> >  

Re: [netmod] Y34 - root node

[Robert Wilton]

Hi Martin,

On 20/08/2015 09:15, Martin Bjorklund wrote:

Andy Bierman  wrote:

On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund  wrote:


Robert Wilton  wrote:


On 18/08/2015 18:22, Andy Bierman wrote:

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.

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


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



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.

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']


What would the real resource location for
"/network/device//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.



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

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




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




Or maybe combine them into one "mount" statement:

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

Re: [netmod] Y34 - root node

[Ladislav Lhotka]

Andy Bierman  writes:

> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund  wrote:
>
>> Robert Wilton  wrote:
>> >
>> >
>> > On 18/08/2015 18:22, Andy Bierman wrote:
>> > > 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.
>> >
>> > 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
>>
>> > > 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//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//.
>> > >
>> > >
>> > >
>> > > 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.
>>
>> 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']
>>
>> > What would the real resource location for
>> > "/network/device//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.
>>
>>
>
> +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.

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

>
> 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).
>
>
>>
>> /martin
>>
>
>
> Andy
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund  wrote:
> 
> > Robert Wilton  wrote:
> > >
> > >
> > > On 18/08/2015 18:22, Andy Bierman wrote:
> > > > 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.
> > >
> > > 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
> >
> > > > 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//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//.
> > > >
> > > >
> > > >
> > > > 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.
> >
> > 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']
> >
> > > What would the real resource location for
> > > "/network/device//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.
> >
> >
> 
> +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).

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

   

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Andy Bierman]

On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> >
> >
> > On 18/08/2015 18:22, Andy Bierman wrote:
> > > 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.
> >
> > 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
>
> > > 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//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//.
> > >
> > >
> > >
> > > 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.
>
> 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']
>
> > What would the real resource location for
> > "/network/device//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.
>
>

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


>
> /martin
>


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Andy Bierman]

On Wed, Aug 19, 2015 at 9:24 AM, t.petch  wrote:

> - Original Message -
> From: "Martin Bjorklund" 
> To: 
> Cc: 
> Sent: Wednesday, August 19, 2015 12:25 PM
> > Robert Wilton  wrote:
> > >
> > > On 18/08/2015 18:22, Andy Bierman wrote:
> > > > 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.
> > >
> > > 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
>
> 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?
>
>

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]

YrRFC  root comments

   20085277 /netconf   Notification streams (XSD, no
YANG at all)
   20106022 /netconf-state  NETCONF monitoring
   20126536 /nacm  NETCONF access control
   20126728 /ipfixIPFIX and PSAMP configuration
   20147223 /interfacesInterface management
/interfaces-state
   2014   7277augment /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


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

Re: [netmod] Y34 - root node

[t . petch]

- Original Message -
From: "Martin Bjorklund" 
To: 
Cc: 
Sent: Wednesday, August 19, 2015 12:25 PM
> Robert Wilton  wrote:
> >
> > On 18/08/2015 18:22, Andy Bierman wrote:
> > > 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.
> >
> > 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

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

> > > 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//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//.
> > >
> > >
> > >
> > > 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.
>
> 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'
]
>
> > What would the real resource location for
> > "/network/device//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
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Robert Wilton]

On 19/08/2015 12:25, Martin Bjorklund wrote:

Robert Wilton  wrote:


What would the real resource location for
"/network/device//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.

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





/martin
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Ladislav Lhotka]

> On 19 Aug 2015, at 13:25, Martin Bjorklund  wrote:
> 
> Robert Wilton  wrote:
>> 
>> 
>> On 18/08/2015 18:22, Andy Bierman wrote:
>>> 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.
>> 
>> 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
> 
>>>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//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//.
>>> 
>>> 
>>> 
>>> 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.
> 
> 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']
> 
>> What would the real resource location for
>> "/network/device//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.

+1

Lada

> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 18/08/2015 18:22, Andy Bierman wrote:
> > 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.
> 
> 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

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

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']

> What would the real resource location for
> "/network/device//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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Robert Wilton]

  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.

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



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.



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.



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.
What would the real resource location for 
"/network/device//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 mailto:netmod-boun...@ietf.org>> on behalf of "Einar
Nilsen-Nygaard (einarnn)" mailto:eina...@cisco.com>>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford mailto:jonat...@hansfords.net>>
Cc: NETMOD Working Group mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y34 - root node

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
mailto:jonat...@hansfords.net>> 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)" mailto:eina...@cisco.com>>

To:
"Andy Bierman" mailto:a...@yumaworks.com>>
Cc:
"NETMOD Working Group" mailto:netmod@ietf.org>>
Sent:
Sat, 8 Aug 2015 11:10:15 +
Subject:
Re: [netmod] Y34 - root node

Re: [netmod] Y34 - root node

[Ladislav Lhotka]

Randy Presuhn  writes:

> Hi -
>
>> From: Andy Bierman
>> Sent: Aug 18, 2015 10:22 AM
>> To: Robert Wilton
>> Cc: NETMOD Working Group
>> Subject: Re: [netmod] Y34 - root node
>>
>> On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton  wrote:
> ...
>> > I think that having fixed paths may end up being too restrictive.
>>
>> This is how languages like SMIv2 and YANG work. A conceptual object
>> is given a permanent "home" within the tree of object identifiers.
>
> But it's *not*, for example, how GDMO works.  The CMIP world
> maintains clear distinctions between the (organizational) hierarchy
> of object identifiers, the conceptual hierarchies of inheritance
> and class composition, and the containment hierarchy of object
> instances.  There the "NAME BINDING" template provides the means
> of describing places where instances of a given class may come
> home to roost.

FWIW, RELAX NG also allows for embedding complete grammars inside
grammars through the "externalRef" pattern.

In our case, the most difficult problem would be XPath expressions and
inter-module leafrefs. That's why I thought packages could also be made
relocatable, provided that they are self-contained and don't use any
references to modules external to the package.

Lada

>
> Randy
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Randy Presuhn]

Hi -

> From: Andy Bierman
> Sent: Aug 18, 2015 10:22 AM
> To: Robert Wilton
> Cc: NETMOD Working Group
> Subject: Re: [netmod] Y34 - root node
>
> On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton  wrote:
...
> > I think that having fixed paths may end up being too restrictive.
>
> This is how languages like SMIv2 and YANG work. A conceptual object
> is given a permanent "home" within the tree of object identifiers.

But it's *not*, for example, how GDMO works.  The CMIP world
maintains clear distinctions between the (organizational) hierarchy
of object identifiers, the conceptual hierarchies of inheritance
and class composition, and the containment hierarchy of object
instances.  There the "NAME BINDING" template provides the means
of describing places where instances of a given class may come
home to roost.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Andy Bierman]

On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton  wrote:

>
>
> On 11/08/2015 08:38, Ladislav Lhotka wrote:
>
>> On 10 Aug 2015, at 22:15, Andy Bierman  wrote:
>>>
>>>
>>>
>>> On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) 
>>> 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.
>>>
>> I think that having fixed paths may end up being too restrictive.
>


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?




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

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.


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

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.

Re: [netmod] Y34 - root node

[Robert Wilton]

On 11/08/2015 08:38, Ladislav Lhotka wrote:

On 10 Aug 2015, at 22:15, Andy Bierman  wrote:



On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee)  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.

I think that having fixed paths may end up being too restrictive.



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.


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


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




Lada






Thanks,
Acee


Andy
  




From: netmod  on behalf of "Einar Nilsen-Nygaard (einarnn)" 

Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford 
Cc: NETMOD Working Group 
Subject: Re: [netmod] Y34 - root node

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  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)" 

To:
"Andy Bierman" 
Cc:
"NETMOD Working Group" 
Sent:
Sat, 8 Aug 2015 11:10:15 +
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.p

Re: [netmod] Y34 - root node

[t . petch]

- Original Message -
From: "Jonathan Hansford" 
cc: "NETMOD Working Group" 
Sent: Monday, August 10, 2015 9:46 AM

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.



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
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 +
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-mod
el
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

 > - Original Message -
 > From: "Andy Bierman"
 > To: "t.petch"
 > Sent: Monday, August 03, 2015 4:10 PM
 >
 > > - Original Message -
 > > From: "Andy Bierman" a...@yumaworks.com [7]
 > > Sent: Saturday, August 01, 2015 7:05 PM
 > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee)
 > >
 >>> On 8/1/15, 2:51 AM, j.schoenwael...@jacobs-university.de [9]>
wrote:
 >>>
 >>> Section 1.1 in
 >>>
 >
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
[10]
 >>> 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.
 > >
 > >
 > > 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.
 >
 >
 >
 > 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
[11]
 >
 > 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

Re: [netmod] Y34 - root node

[Ladislav Lhotka]

> On 10 Aug 2015, at 22:15, Andy Bierman  wrote:
> 
> 
> 
> On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee)  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.
> 

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  on behalf of "Einar Nilsen-Nygaard 
> (einarnn)" 
> Date: Monday, August 10, 2015 at 5:29 AM
> To: Jonathan Hansford 
> Cc: NETMOD Working Group 
> Subject: Re: [netmod] Y34 - root node
> 
> 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  
>> 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)" 
>> 
>> To:
>> "Andy Bierman" 
>> Cc:
>> "NETMOD Working Group" 
>> Sent:
>> Sat, 8 Aug 2015 11:10:15 +
>> 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: "

Re: [netmod] Y34 - root node

[Acee Lindem (acee)]

From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Monday, August 10, 2015 at 4:15 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Einar Nilsen-Nygaard (einarnn)" 
mailto:eina...@cisco.com>>, Jonathan Hansford 
mailto:jonat...@hansfords.net>>, NETMOD Working Group 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y34 - root node



On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) 
mailto:a...@cisco.com>> 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?

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.


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.

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


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.

I wil give your draft a closer read.

Thanks,
Acee








Thanks,
Acee


Andy




From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Einar Nilsen-Nygaard (einarnn)" 
mailto:eina...@cisco.com>>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford mailto:jonat...@hansfords.net>>
Cc: NETMOD Working Group mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y34 - root node

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 
mailto:jonat...@hansfords.net>> 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)" mailto:eina...@cisco.com>>

To:
"Andy Bierman" mailto:a...@yumaworks.com>>
Cc:
"NETMOD Working Group" mailto:netmod@ietf.org>>
Sent:
Sat, 8 Aug 2015 11:10:15 +
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 
mailto:a...@yumaworks.com>> wr

Re: [netmod] Y34 - root node

[Andy Bierman]

On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee)  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,
> Acee
>


Andy


>
>
>
> From: netmod  on behalf of "Einar Nilsen-Nygaard
> (einarnn)" 
> Date: Monday, August 10, 2015 at 5:29 AM
> To: Jonathan Hansford 
> Cc: NETMOD Working Group 
> Subject: Re: [netmod] Y34 - root node
>
> 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 
> 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)" 
>
> To:
> "Andy Bierman" 
> Cc:
> "NETMOD Working Group" 
> Sent:
> Sat, 8 Aug 2015 11:10:15 +
> 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
>>
>> > - Original Message -
>> > From: "Andy Bierman" >
>> > To: "t.petch" 
>> > Sent: Monday, August 03, 2015 4:10 PM
>> >
>> > > - Original Message -
>> > > From: "Andy Bierman" a...@yumaworks.com
>> > > Sent: Saturday, August 01, 2015 7:05 PM
>> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
>> > >
>> >>> On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> wrote:
>> >>>
>> >>> Section 1.1 in
>> >>>
>> > https://

Re: [netmod] Y34 - root node

[Acee Lindem (acee)]

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 mailto:netmod-boun...@ietf.org>> on 
behalf of "Einar Nilsen-Nygaard (einarnn)" 
mailto:eina...@cisco.com>>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford mailto:jonat...@hansfords.net>>
Cc: NETMOD Working Group mailto:netmod@ietf.org>>
Subject: Re: [netmod] Y34 - root node

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 
mailto:jonat...@hansfords.net>> 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)" mailto:eina...@cisco.com>>

To:
"Andy Bierman" mailto:a...@yumaworks.com>>
Cc:
"NETMOD Working Group" mailto:netmod@ietf.org>>
Sent:
Sat, 8 Aug 2015 11:10:15 +
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 
mailto:a...@yumaworks.com>> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch 
mailto:ie...@btconnect.com>> wrote:
- Original Message -
From: "Andy Bierman" mailto:a...@yumaworks.com>>
To: "t.petch" mailto:ie...@btconnect.com>>
Sent: Monday, August 03, 2015 5:17 PM

> - Original Message -
> From: "Andy Bierman" mailto:a...@yumaworks.com>>
> To: "t.petch" mailto:ie...@btconnect.com>>
> Sent: Monday, August 03, 2015 4:10 PM
>
> > - Original Message -
> > From: "Andy Bierman" a...@yumaworks.com<mailto:a...@yumaworks.com>
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> > mailto:a...@cisco.com>>
> >
>>> On 8/1/15, 2:51 AM,  
>>> j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
>>>  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.
> >
> > 
> > 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

Re: [netmod] Y34 - root node

[Andy Bierman]

On Mon, Aug 10, 2015 at 1:46 AM, Jonathan Hansford 
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).
>
>
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  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.




> Jonathan
>


Andy


>
>
>
> - Original Message -
> From:
> "Einar Nilsen-Nygaard (einarnn)" 
>
> To:
> "Andy Bierman" 
> Cc:
> "NETMOD Working Group" 
> Sent:
> Sat, 8 Aug 2015 11:10:15 +
> 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
>>
>> > - Original Message -
>> > From: "Andy Bierman" >
>> > To: "t.petch" 
>> > Sent: Monday, August 03, 2015 4:10 PM
>> >
>> > > - Original Message -
>> > > From: "Andy Bierman" a...@yumaworks.com
>> > > Sent: Saturday, August 01, 2015 7:05 PM
>> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
>> > >
>> >>> On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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.
>> > >
>> > > 
>> > > 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 roo

Re: [netmod] Y34 - root node

[Einar Nilsen-Nygaard (einarnn)]

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 
mailto:jonat...@hansfords.net>> 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)" mailto:eina...@cisco.com>>

To:
"Andy Bierman" mailto:a...@yumaworks.com>>
Cc:
"NETMOD Working Group" mailto:netmod@ietf.org>>
Sent:
Sat, 8 Aug 2015 11:10:15 +
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 
mailto:a...@yumaworks.com>> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch 
mailto:ie...@btconnect.com>> wrote:
- Original Message -
From: "Andy Bierman" mailto:a...@yumaworks.com>>
To: "t.petch" mailto:ie...@btconnect.com>>
Sent: Monday, August 03, 2015 5:17 PM

> - Original Message -
> From: "Andy Bierman" mailto:a...@yumaworks.com>>
> To: "t.petch" mailto:ie...@btconnect.com>>
> Sent: Monday, August 03, 2015 4:10 PM
>
> > - Original Message -
> > From: "Andy Bierman" a...@yumaworks.com<mailto:a...@yumaworks.com>
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> > mailto:a...@cisco.com>>
> >
>>> On 8/1/15, 2:51 AM,  
>>> j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
>>>  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.
> >
> > 
> > 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.
>
> 
>
> 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 orga

Re: [netmod] Y34 - root node

[Jonathan Hansford]

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

 > - Original Message -
 > From: "Andy Bierman" 
 > To: "t.petch" 
 > Sent: Monday, August 03, 2015 4:10 PM
 >
 > > - Original Message -
 > > From: "Andy Bierman" a...@yumaworks.com [7]
 > > Sent: Saturday, August 01, 2015 7:05 PM
 > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
 > >
 >>> On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de [9]>
wrote:
 >>>
 >>> Section 1.1 in
 >>>
 >
https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
[10]
 >>> 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.
 > >
 > > 
 > > 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.
 >
 > 
 >
 > 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
[11]
 >
 > 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?
 Clea

Re: [netmod] Y34 - root node

[Ladislav Lhotka]

Andy Bierman  writes:

> 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
>>
>> > - Original Message -
>> > From: "Andy Bierman" 
>> > To: "t.petch" 
>> > Sent: Monday, August 03, 2015 4:10 PM
>> >
>> > > - Original Message -
>> > > From: "Andy Bierman" a...@yumaworks.com
>> > > Sent: Saturday, August 01, 2015 7:05 PM
>> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
>> > >
>> >>> On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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.
>> > >
>> > > 
>> > > 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.
>> >
>> > 
>> >
>> > 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.
>>
>> 
>>
>> 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  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 dr

Re: [netmod] Y34 - root node

[Einar Nilsen-Nygaard (einarnn)]

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 
mailto:a...@yumaworks.com>> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch 
mailto:ie...@btconnect.com>> wrote:
- Original Message -
From: "Andy Bierman" mailto:a...@yumaworks.com>>
To: "t.petch" mailto:ie...@btconnect.com>>
Sent: Monday, August 03, 2015 5:17 PM

> - Original Message -
> From: "Andy Bierman" mailto:a...@yumaworks.com>>
> To: "t.petch" mailto:ie...@btconnect.com>>
> Sent: Monday, August 03, 2015 4:10 PM
>
> > - Original Message -
> > From: "Andy Bierman" a...@yumaworks.com
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> > mailto:a...@cisco.com>>
> >
>>> On 8/1/15, 2:51 AM,  
>>> j.schoenwael...@jacobs-university.de>
>>>  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.
> >
> > 
> > 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.
>
> 
>
> 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.



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.

Re: [netmod] Y34 - root node

[Andy Bierman]

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
>
> > - Original Message -
> > From: "Andy Bierman" 
> > To: "t.petch" 
> > Sent: Monday, August 03, 2015 4:10 PM
> >
> > > - Original Message -
> > > From: "Andy Bierman" a...@yumaworks.com
> > > Sent: Saturday, August 01, 2015 7:05 PM
> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> > >
> >>> On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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.
> > >
> > > 
> > > 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.
> >
> > 
> >
> > 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.
>
> 
>
> 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  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-p

Re: [netmod] Y34 - root node

[t . petch]

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

> - Original Message -
> From: "Andy Bierman" 
> To: "t.petch" 
> Sent: Monday, August 03, 2015 4:10 PM
>
> > - Original Message -
> > From: "Andy Bierman" a...@yumaworks.com
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> >
>>> On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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.
> >
> > 
> > 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.
>
> 
>
> 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.



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

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

Re: [netmod] Y34 - root node

[Andy Bierman]

On Mon, Aug 3, 2015 at 9:01 AM, t.petch  wrote:

> - Original Message -
> From: "Andy Bierman" 
> To: "t.petch" 
> Cc: "NETMOD Working Group" 
> Sent: Monday, August 03, 2015 4:10 PM
>
> On Mon, Aug 3, 2015 at 7:48 AM, t.petch  wrote:
>
> > - Original Message -
> > From: "Andy Bierman" a...@yumaworks.com
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> > wrote:
> >
> > > Hi Juergen,
> > >
> > > On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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?
> >
> > 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.
> >
> > 
> > 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.
>
> 
>
> 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.



> Tom Petch
> >
>
>

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, increas

Re: [netmod] Y34 - root node

[t . petch]

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

On Mon, Aug 3, 2015 at 7:48 AM, t.petch  wrote:

> - Original Message -
> From: "Andy Bierman" a...@yumaworks.com
> Sent: Saturday, August 01, 2015 7:05 PM
> On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> wrote:
>
> > Hi Juergen,
> >
> > On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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?
>
> 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.
>
> 
> 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.



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!

Tom Petch
>

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)
>
> Thanks,
> > Acee
> >
> Andy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[Andy Bierman]

On Mon, Aug 3, 2015 at 7:48 AM, t.petch  wrote:

> - Original Message -
> From: "Andy Bierman" 
> To: "Acee Lindem (acee)" 
> Cc: "NETMOD Working Group" 
> Sent: Saturday, August 01, 2015 7:05 PM
> Subject: Re: [netmod] Y34
> On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) 
> wrote:
>
> > Hi Juergen,
> >
> > On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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?
>
> 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.
>
> 
> 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.



> Tom Petch
>

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)
>
> Thanks,
> > Acee
> >
> >
> >
> Andy
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

[t . petch]

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

> Hi Juergen,
>
> On 8/1/15, 2:51 AM,  j.schoenwael...@jacobs-university.de> 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?

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.


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


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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Sat, Aug 01, 2015 at 04:51:28PM +, Acee Lindem (acee) 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?
>
>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.

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

>
>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
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Andy Bierman]

On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee)  wrote:

> Hi Juergen,
>
> On 8/1/15, 2:51 AM, "netmod on behalf of Juergen Schoenwaelder"
>  j.schoenwael...@jacobs-university.de> 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?
>
>

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


>
> >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 
> >
> >___
> >netmod mailing list
> >netmod@ietf.org
> >https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Juergen Schoenwaelder]

On Sat, Aug 01, 2015 at 04:51:28PM +, Acee Lindem (acee) 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?

   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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Acee Lindem (acee)]

Hi Juergen, 

On 8/1/15, 2:51 AM, "netmod on behalf of Juergen Schoenwaelder"
 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 
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Juergen Schoenwaelder]

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Andy Bierman]

On Fri, Jul 31, 2015 at 9:46 AM, 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.
>
> Perhaps you'd be willing to have a brain storming session off-line?  (Of
> course, any proposed changes/approaches would be brought to the WG for
> normal WG processing.)
>
>
OK -- send an email invite to the meeting.



> Lou
>
>

Andy


> > For example, a resource directory of symlinks
> > (YANG leaf, type instance-identifier) would allow
> > standard or vendor modules to be supported.
> > The exact location of the data nodes can change over time,
> > and be different on each server.
> >
> >
> > Andy
> >
> > On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger  > > wrote:
> >
> > Andy,
> >
> > Thanks for the good information.  (I'll followup off line a bit if
> > that's okay.) Of course there's a small matter of getting something
> > standardized.
> >
> > Lou
> >
> > On July 27, 2015 2:19:09 AM Andy Bierman  > > wrote:
> >
> >>
> >>
> >> On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger  >> > wrote:
> >>
> >> Andy,
> >>
> >> Have you thought through implications / possibilities for
> >> existing models,  e.g., interfaces?
> >>
> >>
> >>
> >> First we have to define various forms of relocation.
> >>
> >> (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.
> >>
> >> A YANG extension can mark a YANG container or anyxml as a docroot.
> >> Yuma-based code has been doing this for years with a YANG
> >> extension called "root"
> >>
> >> http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554
> >>
> >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html
> >> (See Y34-04)
> >>
> >> The  node below is a document root:
> >>
> >> container servers {
> >>   list server {
> >>   key addr;
> >>   leaf addr { type inet:ip-address; }
> >>   anydata config {
> >>   ncx:root;
> >>   }
> >>   }
> >> }
> >>
> >> XPath evaluation requires certain inputs, including a context node
> >> and a document root.  The 'root' extension tells the tool to use
> >> the node with the 'root' tag as the document root, when processing
> >> XPath within its descendant nodes. Without the tag, the XPath parser
> >> would use 'servers' as the document root, which is incorrect for
> >> the relocated YANG nodes within 'config'.
> >>
> >> (2) Move a subtree within the datastore
> >>
> >> This is the hardest (of course) because it involves moving the
> >> context node
> >> not the document root. It is possible for tools to get fooled
> >> about the intent
> >> of the XPath writer.  Basically the tool has to remember the
> >> original context node,
> >> and do some complicated data manipulation, processing [4] Step
> >> in XPath 1.0.  Multiple relocated subtrees gets even more
> complicated.
> >>
> >> It may be possible to come up with some guidelines on XPath to
> avoid.
> >> Basically any Xpath that selects nodes by specific names can be
> >> relocated automatically.  Nodes selected by function, wildcard,
> >> axis, etc.
> >> will not be so easy.
> >>
> >>
> >>
> >>
> >> Thanks,
> >> Lou
> >>
> >>
> >>
> >> Andy
> >>
> >>
> >> On July 26, 2015 4:41:32 PM Andy Bierman  >> > wrote:
> >>
> >>> Hi Acee,
> >>>
> >>> I agree that "Relocatable YANG" would be very useful, and
> >>> have been
> >>> thinking about the problem for awhile.  I think the key is to
> >>> precisely
> >>> define a protocol-independent document root for each of the
> >>> various
> >>> YANG XPath contexts.  In most cases the expression can be
> >>> automatically relocated to an ancestor root.  For the rest, a
> >>> YANG mechanism is needed to tell the compiler to force
> evaluation
> >>> on the old docroot (not the new docroot ancestor).
> >>>
> >>>
> >>> Andy
> >>>
> >>>
> >>> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee)
> >>> mailto:a...@cisco.com>> wrote:
> >>>
> >>> I think being able to place a given model anywhere in 

Re: [netmod] Y34

[Lou Berger]

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.

Perhaps you'd be willing to have a brain storming session off-line?  (Of
course, any proposed changes/approaches would be brought to the WG for
normal WG processing.)

Lou

> For example, a resource directory of symlinks
> (YANG leaf, type instance-identifier) would allow
> standard or vendor modules to be supported.
> The exact location of the data nodes can change over time,
> and be different on each server.
> 
> 
> Andy
> 
> On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger  > wrote:
> 
> Andy,
> 
> Thanks for the good information.  (I'll followup off line a bit if
> that's okay.) Of course there's a small matter of getting something
> standardized.
> 
> Lou
> 
> On July 27, 2015 2:19:09 AM Andy Bierman  > wrote:
> 
>>
>>
>> On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger > > wrote:
>>
>> Andy,
>>
>> Have you thought through implications / possibilities for
>> existing models,  e.g., interfaces?
>>
>>
>>
>> First we have to define various forms of relocation.
>>
>> (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.
>>
>> A YANG extension can mark a YANG container or anyxml as a docroot.
>> Yuma-based code has been doing this for years with a YANG
>> extension called "root"
>>
>> http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554
>>
>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html
>> (See Y34-04)
>>
>> The  node below is a document root:
>>
>> container servers {
>>   list server {
>>   key addr;
>>   leaf addr { type inet:ip-address; }
>>   anydata config {
>>   ncx:root;
>>   }
>>   }
>> }
>>
>> XPath evaluation requires certain inputs, including a context node
>> and a document root.  The 'root' extension tells the tool to use
>> the node with the 'root' tag as the document root, when processing
>> XPath within its descendant nodes. Without the tag, the XPath parser
>> would use 'servers' as the document root, which is incorrect for
>> the relocated YANG nodes within 'config'.
>>
>> (2) Move a subtree within the datastore
>>
>> This is the hardest (of course) because it involves moving the
>> context node
>> not the document root. It is possible for tools to get fooled
>> about the intent
>> of the XPath writer.  Basically the tool has to remember the
>> original context node,
>> and do some complicated data manipulation, processing [4] Step
>> in XPath 1.0.  Multiple relocated subtrees gets even more complicated.
>>
>> It may be possible to come up with some guidelines on XPath to avoid.
>> Basically any Xpath that selects nodes by specific names can be
>> relocated automatically.  Nodes selected by function, wildcard,
>> axis, etc.
>> will not be so easy.
>>  
>>
>>  
>>
>> Thanks,
>> Lou
>>
>>
>>
>> Andy
>>  
>>
>> On July 26, 2015 4:41:32 PM Andy Bierman > > wrote:
>>
>>> Hi Acee,
>>>
>>> I agree that "Relocatable YANG" would be very useful, and
>>> have been
>>> thinking about the problem for awhile.  I think the key is to
>>> precisely
>>> define a protocol-independent document root for each of the
>>> various
>>> YANG XPath contexts.  In most cases the expression can be
>>> automatically relocated to an ancestor root.  For the rest, a
>>> YANG mechanism is needed to tell the compiler to force evaluation
>>> on the old docroot (not the new docroot ancestor).
>>>
>>>
>>> Andy
>>>
>>>
>>> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee)
>>> mailto:a...@cisco.com>> wrote:
>>>
>>> I think being able to place a given model anywhere in the
>>> device tree
>>> would be useful and this would allow a model to be rooted
>>> in different
>>> locations on different devices. Similarly, we’d need the
>>> ability to prefix
>>> XPATH references to data nodes in the model with the root.
>>> Thanks,
>>> Acee
>>>
>>>  

Re: [netmod] Y34

[Andy Bierman]

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.

For example, a resource directory of symlinks
(YANG leaf, type instance-identifier) would allow
standard or vendor modules to be supported.
The exact location of the data nodes can change over time,
and be different on each server.


Andy

On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger  wrote:

>   Andy,
>
> Thanks for the good information.  (I'll followup off line a bit if that's
> okay.) Of course there's a small matter of getting something standardized.
>
> Lou
>
> On July 27, 2015 2:19:09 AM Andy Bierman  wrote:
>
>>
>>
>> On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger  wrote:
>>
>>>   Andy,
>>>
>>> Have you thought through implications / possibilities for existing
>>> models,  e.g., interfaces?
>>>
>>
>>
>> First we have to define various forms of relocation.
>>
>> (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.
>>
>> A YANG extension can mark a YANG container or anyxml as a docroot.
>> Yuma-based code has been doing this for years with a YANG
>> extension called "root"
>>
>> http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554
>>
>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html
>> (See Y34-04)
>>
>> The  node below is a document root:
>>
>> container servers {
>>   list server {
>>   key addr;
>>   leaf addr { type inet:ip-address; }
>>   anydata config {
>>   ncx:root;
>>   }
>>   }
>> }
>>
>> XPath evaluation requires certain inputs, including a context node
>> and a document root.  The 'root' extension tells the tool to use
>> the node with the 'root' tag as the document root, when processing
>> XPath within its descendant nodes. Without the tag, the XPath parser
>> would use 'servers' as the document root, which is incorrect for
>> the relocated YANG nodes within 'config'.
>>
>> (2) Move a subtree within the datastore
>>
>> This is the hardest (of course) because it involves moving the context
>> node
>> not the document root. It is possible for tools to get fooled about the
>> intent
>> of the XPath writer.  Basically the tool has to remember the original
>> context node,
>> and do some complicated data manipulation, processing [4] Step
>> in XPath 1.0.  Multiple relocated subtrees gets even more complicated.
>>
>> It may be possible to come up with some guidelines on XPath to avoid.
>> Basically any Xpath that selects nodes by specific names can be
>> relocated automatically.  Nodes selected by function, wildcard, axis, etc.
>> will not be so easy.
>>
>>
>>
>>
>>> Thanks,
>>> Lou
>>>
>>
>>
>> Andy
>>
>>
>>>   On July 26, 2015 4:41:32 PM Andy Bierman  wrote:
>>>
 Hi Acee,

 I agree that "Relocatable YANG" would be very useful, and have been
 thinking about the problem for awhile.  I think the key is to precisely
 define a protocol-independent document root for each of the various
 YANG XPath contexts.  In most cases the expression can be
 automatically relocated to an ancestor root.  For the rest, a
 YANG mechanism is needed to tell the compiler to force evaluation
 on the old docroot (not the new docroot ancestor).


 Andy


 On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) 
 wrote:

> I think being able to place a given model anywhere in the device tree
> would be useful and this would allow a model to be rooted in different
> locations on different devices. Similarly, we’d need the ability to
> prefix
> XPATH references to data nodes in the model with the root.
> Thanks,
> Acee
>
> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
>  j.schoenwael...@jacobs-university.de> wrote:
>
> >Lada,
> >
> >Y34 is closed and I have not seen any new argument here that indicates
> >we made a major mistake with the resolution of Y34. As such, Y34
> >remains closed.
> >
> >If you want to discuss new ideas to relocate or "symlink" data models,
> >please do so in a separate thread. (And no, we do not accept new
> >issues for YANG 1.1 either at this point in time.)
> >
> >/js
> >
> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
> >>
> >> > On 20 Jul 2015, at 19:29, Andy Bierman 
> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
> >>wrote:
> >> >
> >> > > On 20 Jul 2015, at 17:00, Andy Bierman 
> wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Jul 20, 

Re: [netmod] Y34

[Lou Berger]

Andy,

Thanks for the good information.  (I'll followup off line a bit if that's 
okay.) Of course there's a small matter of getting something standardized.


Lou


On July 27, 2015 2:19:09 AM Andy Bierman  wrote:


On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger  wrote:

>   Andy,
>
> Have you thought through implications / possibilities for existing
> models,  e.g., interfaces?
>


First we have to define various forms of relocation.

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

A YANG extension can mark a YANG container or anyxml as a docroot.
Yuma-based code has been doing this for years with a YANG
extension called "root"

http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554

http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html
(See Y34-04)

The  node below is a document root:

container servers {
  list server {
  key addr;
  leaf addr { type inet:ip-address; }
  anydata config {
  ncx:root;
  }
  }
}

XPath evaluation requires certain inputs, including a context node
and a document root.  The 'root' extension tells the tool to use
the node with the 'root' tag as the document root, when processing
XPath within its descendant nodes. Without the tag, the XPath parser
would use 'servers' as the document root, which is incorrect for
the relocated YANG nodes within 'config'.

(2) Move a subtree within the datastore

This is the hardest (of course) because it involves moving the context node
not the document root. It is possible for tools to get fooled about the
intent
of the XPath writer.  Basically the tool has to remember the original
context node,
and do some complicated data manipulation, processing [4] Step
in XPath 1.0.  Multiple relocated subtrees gets even more complicated.

It may be possible to come up with some guidelines on XPath to avoid.
Basically any Xpath that selects nodes by specific names can be
relocated automatically.  Nodes selected by function, wildcard, axis, etc.
will not be so easy.




> Thanks,
> Lou
>


Andy


>   On July 26, 2015 4:41:32 PM Andy Bierman  wrote:
>
>> Hi Acee,
>>
>> I agree that "Relocatable YANG" would be very useful, and have been
>> thinking about the problem for awhile.  I think the key is to precisely
>> define a protocol-independent document root for each of the various
>> YANG XPath contexts.  In most cases the expression can be
>> automatically relocated to an ancestor root.  For the rest, a
>> YANG mechanism is needed to tell the compiler to force evaluation
>> on the old docroot (not the new docroot ancestor).
>>
>>
>> Andy
>>
>>
>> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) 
>> wrote:
>>
>>> I think being able to place a given model anywhere in the device tree
>>> would be useful and this would allow a model to be rooted in different
>>> locations on different devices. Similarly, we’d need the ability to
>>> prefix
>>> XPATH references to data nodes in the model with the root.
>>> Thanks,
>>> Acee
>>>
>>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
>>> >> j.schoenwael...@jacobs-university.de> wrote:
>>>
>>> >Lada,
>>> >
>>> >Y34 is closed and I have not seen any new argument here that indicates
>>> >we made a major mistake with the resolution of Y34. As such, Y34
>>> >remains closed.
>>> >
>>> >If you want to discuss new ideas to relocate or "symlink" data models,
>>> >please do so in a separate thread. (And no, we do not accept new
>>> >issues for YANG 1.1 either at this point in time.)
>>> >
>>> >/js
>>> >
>>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>> >>
>>> >> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
>>> >>wrote:
>>> >> >
>>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman 
>>> wrote:
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
>>> >>wrote:
>>> >> > >
>>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman 
>>> wrote:
>>> >> > > >
>>> >> > > > Hi,
>>> >> > > >
>>> >> > > > Can you explain why we need 2 broken anyxmls?
>>> >> > > > (The original and a synonym?)  The whole point of
>>> >> > > > anydata is that it does not have XML cruft in it.
>>> >> > >
>>> >> > > Yes, I understand this was your main priority. For implementors
>>> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>> >>at all.
>>> >> > >
>>> >> > >
>>> >> > > yes it is an issue.
>>> >> > > We need something to model a container full of arbitrary YANG data
>>> >>nodes.
>>> >> > > This is something that can be applied to the contents of a
>>> >>datastore.
>>> >> >
>>> >> > anyxml can do that, too.
>>> >> >
>>> >> >
>>> >> > the WG already decided it can't.
>>> >> > The extra XML PIs, etc. are not accepted by all servers, rem

Re: [netmod] Y34

[Juergen Schoenwaelder]

I do not think this is Y34. Relocating YANG models is not covered by
any of the YANG 1.1 issues as far as I can tell and issue submission
closed about a year ago. I suggest someone interested in such a
feature writes an independent I-D. And as usual, the devil is in the
details.

/js

On Sun, Jul 26, 2015 at 05:49:17PM +, Acee Lindem (acee) wrote:
> I think being able to place a given model anywhere in the device tree
> would be useful and this would allow a model to be rooted in different
> locations on different devices. Similarly, we’d need the ability to prefix
> XPATH references to data nodes in the model with the root.
> Thanks,
> Acee 
> 
> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
>  j.schoenwael...@jacobs-university.de> wrote:
> 
> >Lada,
> >
> >Y34 is closed and I have not seen any new argument here that indicates
> >we made a major mistake with the resolution of Y34. As such, Y34
> >remains closed.
> >
> >If you want to discuss new ideas to relocate or "symlink" data models,
> >please do so in a separate thread. (And no, we do not accept new
> >issues for YANG 1.1 either at this point in time.)
> >
> >/js
> >
> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
> >> 
> >> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
> >> > 
> >> > 
> >> > 
> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
> >>wrote:
> >> > 
> >> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
> >>wrote:
> >> > >
> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > > Can you explain why we need 2 broken anyxmls?
> >> > > > (The original and a synonym?)  The whole point of
> >> > > > anydata is that it does not have XML cruft in it.
> >> > >
> >> > > Yes, I understand this was your main priority. For implementors
> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue
> >>at all.
> >> > >
> >> > >
> >> > > yes it is an issue.
> >> > > We need something to model a container full of arbitrary YANG data
> >>nodes.
> >> > > This is something that can be applied to the contents of a
> >>datastore.
> >> > 
> >> > anyxml can do that, too.
> >> > 
> >> > 
> >> > the WG already decided it can't.
> >> > The extra XML PIs, etc. are not accepted by all servers, remember?
> >> > There is no use for the extra stuff in the datastore.
> >> >  I don't see why we need 2 anyxml constructs that are not
> >> > supported by the industry.  One is already too many.
> >> 
> >> I agree, but this is what we are going to have. My proposal was to have
> >>just one with two different names.
> >> 
> >> > 
> >> > 
> >> > >
> >> > >
> >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
> >>with no (YANG) schema available. My only complaint to “anyxml” has
> >>always been that it is a misnomer for encodings other than XML.
> >> > >
> >> > > The message encoding on the wire is not the same issue
> >> > > as the contents of a datastore.  Our server stores its own
> >> > > internal data structures.  XML, JSON, CBOR are just message
> >> > > encoding formats between client and server.  The datastore
> >> > > is not encoded in any of these formats.
> >> > 
> >> > The payload of anyxml needn’t directly map to a data subtree in the
> >>usual sense.
> >> > 
> >> > that's precisely the difference between anyxml and anydata.
> >> > The anydata node MUST map directly into data subtrees.
> >> 
> >> If the server doesn’t know the YANG data model at run time (which is
> >>possible) then it cannot do it - for instance, it cannot properly map
> >>module names to namespace URI or handle lists.
> >> 
> >> > 
> >> >  
> >> > 
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > >
> >> > > > I also don't get the value of a single top-level node called
> >>'device'
> >> > > > that every YANG model on the planet is supposed to augment.
> >> > > > Can you explain why a protocol operation to retrieve the
> >> > > > document root (/) is not sufficient for the top-level node?
> >> > >
> >> > > I don’t intend to defend their model, the more serious problem IMO
> >>is that a model for a single device/function may be needed in another
> >>device that hosts many virtualised devices/functions of the former type.
> >>We don’t have a good solution for this rather typical situation.
> >> > >
> >> > > But a single container called "whatever" provides no such
> >>aggregation.
> >> > > You would need a list for that. And the NMS might have multiple
> >> > > layers of hierarchy to represent various aggregations.  The NP
> >> > > container called "device" is not helpful for aggregation.
> >> > 
> >> > The parent node can be a list as well. The “root” node would be like
> >>a mount point in a Unix filesystem.
> >> > 
> >> > 
> >> > Are you saying all data on a device needs to be in a top-level list
> >>called 'device'
> >> > because an NMS might exist that  wants to ha

Re: [netmod] Y34

[Ladislav Lhotka]

Andy Bierman  writes:

> Hi Acee,
>
> I agree that "Relocatable YANG" would be very useful, and have been
> thinking about the problem for awhile.  I think the key is to precisely
> define a protocol-independent document root for each of the various
> YANG XPath contexts.  In most cases the expression can be
> automatically relocated to an ancestor root.  For the rest, a
> YANG mechanism is needed to tell the compiler to force evaluation
> on the old docroot (not the new docroot ancestor).

The authors of DSDL family of schema languages realized the utility of
"compound documents" and designed NVDL language for their validation. It's
nicely described here:

http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compound.html

I think most of NVDL concepts could be applied to YANG, too, perhaps as
a part of external conformance specification.

As for XPath expressions, the specification could map each namespace to
a root that has to be prepended to every absolute XPath that starts with
a node from the given namespace. The existing modules could then
continue to work unchanged.

Actually, this is being done already now: when validating an XML
document containing YANG-modelled data, an initial segment often needs
to be prepended to all absolute XPaths, e.g. "/nc:rpc-reply/nc:data",
depending on the type of the document.

Lada

>
>
> Andy
>
>
> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee)  wrote:
>
>> I think being able to place a given model anywhere in the device tree
>> would be useful and this would allow a model to be rooted in different
>> locations on different devices. Similarly, we’d need the ability to prefix
>> XPATH references to data nodes in the model with the root.
>> Thanks,
>> Acee
>>
>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
>> > j.schoenwael...@jacobs-university.de> wrote:
>>
>> >Lada,
>> >
>> >Y34 is closed and I have not seen any new argument here that indicates
>> >we made a major mistake with the resolution of Y34. As such, Y34
>> >remains closed.
>> >
>> >If you want to discuss new ideas to relocate or "symlink" data models,
>> >please do so in a separate thread. (And no, we do not accept new
>> >issues for YANG 1.1 either at this point in time.)
>> >
>> >/js
>> >
>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>> >>
>> >> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
>> >>wrote:
>> >> >
>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
>> >>wrote:
>> >> > >
>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman 
>> wrote:
>> >> > > >
>> >> > > > Hi,
>> >> > > >
>> >> > > > Can you explain why we need 2 broken anyxmls?
>> >> > > > (The original and a synonym?)  The whole point of
>> >> > > > anydata is that it does not have XML cruft in it.
>> >> > >
>> >> > > Yes, I understand this was your main priority. For implementors
>> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>> >>at all.
>> >> > >
>> >> > >
>> >> > > yes it is an issue.
>> >> > > We need something to model a container full of arbitrary YANG data
>> >>nodes.
>> >> > > This is something that can be applied to the contents of a
>> >>datastore.
>> >> >
>> >> > anyxml can do that, too.
>> >> >
>> >> >
>> >> > the WG already decided it can't.
>> >> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> >> > There is no use for the extra stuff in the datastore.
>> >> >  I don't see why we need 2 anyxml constructs that are not
>> >> > supported by the industry.  One is already too many.
>> >>
>> >> I agree, but this is what we are going to have. My proposal was to have
>> >>just one with two different names.
>> >>
>> >> >
>> >> >
>> >> > >
>> >> > >
>> >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
>> >>with no (YANG) schema available. My only complaint to “anyxml” has
>> >>always been that it is a misnomer for encodings other than XML.
>> >> > >
>> >> > > The message encoding on the wire is not the same issue
>> >> > > as the contents of a datastore.  Our server stores its own
>> >> > > internal data structures.  XML, JSON, CBOR are just message
>> >> > > encoding formats between client and server.  The datastore
>> >> > > is not encoded in any of these formats.
>> >> >
>> >> > The payload of anyxml needn’t directly map to a data subtree in the
>> >>usual sense.
>> >> >
>> >> > that's precisely the difference between anyxml and anydata.
>> >> > The anydata node MUST map directly into data subtrees.
>> >>
>> >> If the server doesn’t know the YANG data model at run time (which is
>> >>possible) then it cannot do it - for instance, it cannot properly map
>> >>module names to namespace URI or handle lists.
>> >>
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > >
>> >> > > > I also don'

Re: [netmod] Y34

[Andy Bierman]

On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger  wrote:

>   Andy,
>
> Have you thought through implications / possibilities for existing
> models,  e.g., interfaces?
>


First we have to define various forms of relocation.

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

A YANG extension can mark a YANG container or anyxml as a docroot.
Yuma-based code has been doing this for years with a YANG
extension called "root"

http://www.netconfcentral.org/modules/yuma-ncx/2013-09-23#root.554

http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html
(See Y34-04)

The  node below is a document root:

container servers {
  list server {
  key addr;
  leaf addr { type inet:ip-address; }
  anydata config {
  ncx:root;
  }
  }
}

XPath evaluation requires certain inputs, including a context node
and a document root.  The 'root' extension tells the tool to use
the node with the 'root' tag as the document root, when processing
XPath within its descendant nodes. Without the tag, the XPath parser
would use 'servers' as the document root, which is incorrect for
the relocated YANG nodes within 'config'.

(2) Move a subtree within the datastore

This is the hardest (of course) because it involves moving the context node
not the document root. It is possible for tools to get fooled about the
intent
of the XPath writer.  Basically the tool has to remember the original
context node,
and do some complicated data manipulation, processing [4] Step
in XPath 1.0.  Multiple relocated subtrees gets even more complicated.

It may be possible to come up with some guidelines on XPath to avoid.
Basically any Xpath that selects nodes by specific names can be
relocated automatically.  Nodes selected by function, wildcard, axis, etc.
will not be so easy.




> Thanks,
> Lou
>


Andy


>   On July 26, 2015 4:41:32 PM Andy Bierman  wrote:
>
>> Hi Acee,
>>
>> I agree that "Relocatable YANG" would be very useful, and have been
>> thinking about the problem for awhile.  I think the key is to precisely
>> define a protocol-independent document root for each of the various
>> YANG XPath contexts.  In most cases the expression can be
>> automatically relocated to an ancestor root.  For the rest, a
>> YANG mechanism is needed to tell the compiler to force evaluation
>> on the old docroot (not the new docroot ancestor).
>>
>>
>> Andy
>>
>>
>> On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee) 
>> wrote:
>>
>>> I think being able to place a given model anywhere in the device tree
>>> would be useful and this would allow a model to be rooted in different
>>> locations on different devices. Similarly, we’d need the ability to
>>> prefix
>>> XPATH references to data nodes in the model with the root.
>>> Thanks,
>>> Acee
>>>
>>> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
>>> >> j.schoenwael...@jacobs-university.de> wrote:
>>>
>>> >Lada,
>>> >
>>> >Y34 is closed and I have not seen any new argument here that indicates
>>> >we made a major mistake with the resolution of Y34. As such, Y34
>>> >remains closed.
>>> >
>>> >If you want to discuss new ideas to relocate or "symlink" data models,
>>> >please do so in a separate thread. (And no, we do not accept new
>>> >issues for YANG 1.1 either at this point in time.)
>>> >
>>> >/js
>>> >
>>> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>> >>
>>> >> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
>>> >>wrote:
>>> >> >
>>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman 
>>> wrote:
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
>>> >>wrote:
>>> >> > >
>>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman 
>>> wrote:
>>> >> > > >
>>> >> > > > Hi,
>>> >> > > >
>>> >> > > > Can you explain why we need 2 broken anyxmls?
>>> >> > > > (The original and a synonym?)  The whole point of
>>> >> > > > anydata is that it does not have XML cruft in it.
>>> >> > >
>>> >> > > Yes, I understand this was your main priority. For implementors
>>> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>> >>at all.
>>> >> > >
>>> >> > >
>>> >> > > yes it is an issue.
>>> >> > > We need something to model a container full of arbitrary YANG data
>>> >>nodes.
>>> >> > > This is something that can be applied to the contents of a
>>> >>datastore.
>>> >> >
>>> >> > anyxml can do that, too.
>>> >> >
>>> >> >
>>> >> > the WG already decided it can't.
>>> >> > The extra XML PIs, etc. are not accepted by all servers, remember?
>>> >> > There is no use for the extra stuff in the datastore.
>>> >> >  I don't see why we need 2 anyxml constructs that are not
>>> >> > supported by the industry.  One is already too many.
>>> >>
>>> >> I ag

Re: [netmod] Y34

[Lou Berger]

Andy,

Have you thought through implications / possibilities for existing models,  
e.g., interfaces?


Thanks,
Lou


On July 26, 2015 4:41:32 PM Andy Bierman  wrote:


Hi Acee,

I agree that "Relocatable YANG" would be very useful, and have been
thinking about the problem for awhile.  I think the key is to precisely
define a protocol-independent document root for each of the various
YANG XPath contexts.  In most cases the expression can be
automatically relocated to an ancestor root.  For the rest, a
YANG mechanism is needed to tell the compiler to force evaluation
on the old docroot (not the new docroot ancestor).


Andy


On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee)  wrote:

> I think being able to place a given model anywhere in the device tree
> would be useful and this would allow a model to be rooted in different
> locations on different devices. Similarly, we’d need the ability to prefix
> XPATH references to data nodes in the model with the root.
> Thanks,
> Acee
>
> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
>  j.schoenwael...@jacobs-university.de> wrote:
>
> >Lada,
> >
> >Y34 is closed and I have not seen any new argument here that indicates
> >we made a major mistake with the resolution of Y34. As such, Y34
> >remains closed.
> >
> >If you want to discuss new ideas to relocate or "symlink" data models,
> >please do so in a separate thread. (And no, we do not accept new
> >issues for YANG 1.1 either at this point in time.)
> >
> >/js
> >
> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
> >>
> >> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
> >>wrote:
> >> >
> >> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
> >>wrote:
> >> > >
> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman 
> wrote:
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > > Can you explain why we need 2 broken anyxmls?
> >> > > > (The original and a synonym?)  The whole point of
> >> > > > anydata is that it does not have XML cruft in it.
> >> > >
> >> > > Yes, I understand this was your main priority. For implementors
> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue
> >>at all.
> >> > >
> >> > >
> >> > > yes it is an issue.
> >> > > We need something to model a container full of arbitrary YANG data
> >>nodes.
> >> > > This is something that can be applied to the contents of a
> >>datastore.
> >> >
> >> > anyxml can do that, too.
> >> >
> >> >
> >> > the WG already decided it can't.
> >> > The extra XML PIs, etc. are not accepted by all servers, remember?
> >> > There is no use for the extra stuff in the datastore.
> >> >  I don't see why we need 2 anyxml constructs that are not
> >> > supported by the industry.  One is already too many.
> >>
> >> I agree, but this is what we are going to have. My proposal was to have
> >>just one with two different names.
> >>
> >> >
> >> >
> >> > >
> >> > >
> >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
> >>with no (YANG) schema available. My only complaint to “anyxml” has
> >>always been that it is a misnomer for encodings other than XML.
> >> > >
> >> > > The message encoding on the wire is not the same issue
> >> > > as the contents of a datastore.  Our server stores its own
> >> > > internal data structures.  XML, JSON, CBOR are just message
> >> > > encoding formats between client and server.  The datastore
> >> > > is not encoded in any of these formats.
> >> >
> >> > The payload of anyxml needn’t directly map to a data subtree in the
> >>usual sense.
> >> >
> >> > that's precisely the difference between anyxml and anydata.
> >> > The anydata node MUST map directly into data subtrees.
> >>
> >> If the server doesn’t know the YANG data model at run time (which is
> >>possible) then it cannot do it - for instance, it cannot properly map
> >>module names to namespace URI or handle lists.
> >>
> >> >
> >> >
> >> >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > >
> >> > > > I also don't get the value of a single top-level node called
> >>'device'
> >> > > > that every YANG model on the planet is supposed to augment.
> >> > > > Can you explain why a protocol operation to retrieve the
> >> > > > document root (/) is not sufficient for the top-level node?
> >> > >
> >> > > I don’t intend to defend their model, the more serious problem IMO
> >>is that a model for a single device/function may be needed in another
> >>device that hosts many virtualised devices/functions of the former type.
> >>We don’t have a good solution for this rather typical situation.
> >> > >
> >> > > But a single container called "whatever" provides no such
> >>aggregation.
> >> > > You would need a list for that. And the NMS might have multiple
> >> > > layers of hierarchy to represent various aggregations.  The NP
> >> > > container called "devic

Re: [netmod] Y34

[Andy Bierman]

Hi Acee,

I agree that "Relocatable YANG" would be very useful, and have been
thinking about the problem for awhile.  I think the key is to precisely
define a protocol-independent document root for each of the various
YANG XPath contexts.  In most cases the expression can be
automatically relocated to an ancestor root.  For the rest, a
YANG mechanism is needed to tell the compiler to force evaluation
on the old docroot (not the new docroot ancestor).


Andy


On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee)  wrote:

> I think being able to place a given model anywhere in the device tree
> would be useful and this would allow a model to be rooted in different
> locations on different devices. Similarly, we’d need the ability to prefix
> XPATH references to data nodes in the model with the root.
> Thanks,
> Acee
>
> On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
>  j.schoenwael...@jacobs-university.de> wrote:
>
> >Lada,
> >
> >Y34 is closed and I have not seen any new argument here that indicates
> >we made a major mistake with the resolution of Y34. As such, Y34
> >remains closed.
> >
> >If you want to discuss new ideas to relocate or "symlink" data models,
> >please do so in a separate thread. (And no, we do not accept new
> >issues for YANG 1.1 either at this point in time.)
> >
> >/js
> >
> >On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
> >>
> >> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
> >>wrote:
> >> >
> >> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
> >>wrote:
> >> > >
> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman 
> wrote:
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > > Can you explain why we need 2 broken anyxmls?
> >> > > > (The original and a synonym?)  The whole point of
> >> > > > anydata is that it does not have XML cruft in it.
> >> > >
> >> > > Yes, I understand this was your main priority. For implementors
> >>using off-the-shelf XML parsers and tools the XML cruft is not an issue
> >>at all.
> >> > >
> >> > >
> >> > > yes it is an issue.
> >> > > We need something to model a container full of arbitrary YANG data
> >>nodes.
> >> > > This is something that can be applied to the contents of a
> >>datastore.
> >> >
> >> > anyxml can do that, too.
> >> >
> >> >
> >> > the WG already decided it can't.
> >> > The extra XML PIs, etc. are not accepted by all servers, remember?
> >> > There is no use for the extra stuff in the datastore.
> >> >  I don't see why we need 2 anyxml constructs that are not
> >> > supported by the industry.  One is already too many.
> >>
> >> I agree, but this is what we are going to have. My proposal was to have
> >>just one with two different names.
> >>
> >> >
> >> >
> >> > >
> >> > >
> >> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
> >>with no (YANG) schema available. My only complaint to “anyxml” has
> >>always been that it is a misnomer for encodings other than XML.
> >> > >
> >> > > The message encoding on the wire is not the same issue
> >> > > as the contents of a datastore.  Our server stores its own
> >> > > internal data structures.  XML, JSON, CBOR are just message
> >> > > encoding formats between client and server.  The datastore
> >> > > is not encoded in any of these formats.
> >> >
> >> > The payload of anyxml needn’t directly map to a data subtree in the
> >>usual sense.
> >> >
> >> > that's precisely the difference between anyxml and anydata.
> >> > The anydata node MUST map directly into data subtrees.
> >>
> >> If the server doesn’t know the YANG data model at run time (which is
> >>possible) then it cannot do it - for instance, it cannot properly map
> >>module names to namespace URI or handle lists.
> >>
> >> >
> >> >
> >> >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > >
> >> > > > I also don't get the value of a single top-level node called
> >>'device'
> >> > > > that every YANG model on the planet is supposed to augment.
> >> > > > Can you explain why a protocol operation to retrieve the
> >> > > > document root (/) is not sufficient for the top-level node?
> >> > >
> >> > > I don’t intend to defend their model, the more serious problem IMO
> >>is that a model for a single device/function may be needed in another
> >>device that hosts many virtualised devices/functions of the former type.
> >>We don’t have a good solution for this rather typical situation.
> >> > >
> >> > > But a single container called "whatever" provides no such
> >>aggregation.
> >> > > You would need a list for that. And the NMS might have multiple
> >> > > layers of hierarchy to represent various aggregations.  The NP
> >> > > container called "device" is not helpful for aggregation.
> >> >
> >> > The parent node can be a list as well. The “root” node would be like
> >>a mount point in a Unix filesystem.
> >> >
> >> 

Re: [netmod] Y34

[Lou Berger]

I completely agree.  We definitely will make use if this in the new models 
being developed in the routing area.


Lou


On July 26, 2015 1:50:00 PM "Acee Lindem (acee)"  wrote:


I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we’d need the ability to prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates
>we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" data models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>>
>> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
>> >
>> >
>> >
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
>>wrote:
>> >
>> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)  The whole point of
>> > > > anydata is that it does not have XML cruft in it.
>> > >
>> > > Yes, I understand this was your main priority. For implementors
>>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary YANG data
>>nodes.
>> > > This is something that can be applied to the contents of a
>>datastore.
>> >
>> > anyxml can do that, too.
>> >
>> >
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> > There is no use for the extra stuff in the datastore.
>> >  I don't see why we need 2 anyxml constructs that are not
>> > supported by the industry.  One is already too many.
>>
>> I agree, but this is what we are going to have. My proposal was to have
>>just one with two different names.
>>
>> >
>> >
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
>>with no (YANG) schema available. My only complaint to “anyxml” has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue
>> > > as the contents of a datastore.  Our server stores its own
>> > > internal data structures.  XML, JSON, CBOR are just message
>> > > encoding formats between client and server.  The datastore
>> > > is not encoded in any of these formats.
>> >
>> > The payload of anyxml needn’t directly map to a data subtree in the
>>usual sense.
>> >
>> > that's precisely the difference between anyxml and anydata.
>> > The anydata node MUST map directly into data subtrees.
>>
>> If the server doesn’t know the YANG data model at run time (which is
>>possible) then it cannot do it - for instance, it cannot properly map
>>module names to namespace URI or handle lists.
>>
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-level node called
>>'device'
>> > > > that every YANG model on the planet is supposed to augment.
>> > > > Can you explain why a protocol operation to retrieve the
>> > > > document root (/) is not sufficient for the top-level node?
>> > >
>> > > I don’t intend to defend their model, the more serious problem IMO
>>is that a model for a single device/function may be needed in another
>>device that hosts many virtualised devices/functions of the former type.
>>We don’t have a good solution for this rather typical situation.
>> > >
>> > > But a single container called "whatever" provides no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have multiple
>> > > layers of hierarchy to represent various aggregations.  The NP
>> > > container called "device" is not helpful for aggregation.
>> >
>> > The parent node can be a list as well. The “root” node would be like
>>a mount point in a Unix filesystem.
>> >
>> >
>> > Are you saying all data on a device needs to be in a top-level list
>>called 'device'
>> > because an NMS might exist that  wants to have the datastores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own
>>container or
>> > lists.  It does not need the device to mirror its own structure.
>>
>> As I said, I don’t care that much about the “device” container. What
>>would be really useful is to have the possibility to do e.g. this:
>>
>> virtual-node* [name]
>> name
>> if:interfaces
>> ...
>>
>> to support the use case where all virtual nodes are managed by the sa

Re: [netmod] Y34

[Acee Lindem (acee)]

I think being able to place a given model anywhere in the device tree
would be useful and this would allow a model to be rooted in different
locations on different devices. Similarly, we’d need the ability to prefix
XPATH references to data nodes in the model with the root.
Thanks,
Acee 

On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>Lada,
>
>Y34 is closed and I have not seen any new argument here that indicates
>we made a major mistake with the resolution of Y34. As such, Y34
>remains closed.
>
>If you want to discuss new ideas to relocate or "symlink" data models,
>please do so in a separate thread. (And no, we do not accept new
>issues for YANG 1.1 either at this point in time.)
>
>/js
>
>On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>> 
>> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
>> > 
>> > 
>> > 
>> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka 
>>wrote:
>> > 
>> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka 
>>wrote:
>> > >
>> > > > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > Can you explain why we need 2 broken anyxmls?
>> > > > (The original and a synonym?)  The whole point of
>> > > > anydata is that it does not have XML cruft in it.
>> > >
>> > > Yes, I understand this was your main priority. For implementors
>>using off-the-shelf XML parsers and tools the XML cruft is not an issue
>>at all.
>> > >
>> > >
>> > > yes it is an issue.
>> > > We need something to model a container full of arbitrary YANG data
>>nodes.
>> > > This is something that can be applied to the contents of a
>>datastore.
>> > 
>> > anyxml can do that, too.
>> > 
>> > 
>> > the WG already decided it can't.
>> > The extra XML PIs, etc. are not accepted by all servers, remember?
>> > There is no use for the extra stuff in the datastore.
>> >  I don't see why we need 2 anyxml constructs that are not
>> > supported by the industry.  One is already too many.
>> 
>> I agree, but this is what we are going to have. My proposal was to have
>>just one with two different names.
>> 
>> > 
>> > 
>> > >
>> > >
>> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/…
>>with no (YANG) schema available. My only complaint to “anyxml” has
>>always been that it is a misnomer for encodings other than XML.
>> > >
>> > > The message encoding on the wire is not the same issue
>> > > as the contents of a datastore.  Our server stores its own
>> > > internal data structures.  XML, JSON, CBOR are just message
>> > > encoding formats between client and server.  The datastore
>> > > is not encoded in any of these formats.
>> > 
>> > The payload of anyxml needn’t directly map to a data subtree in the
>>usual sense.
>> > 
>> > that's precisely the difference between anyxml and anydata.
>> > The anydata node MUST map directly into data subtrees.
>> 
>> If the server doesn’t know the YANG data model at run time (which is
>>possible) then it cannot do it - for instance, it cannot properly map
>>module names to namespace URI or handle lists.
>> 
>> > 
>> >  
>> > 
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > > I also don't get the value of a single top-level node called
>>'device'
>> > > > that every YANG model on the planet is supposed to augment.
>> > > > Can you explain why a protocol operation to retrieve the
>> > > > document root (/) is not sufficient for the top-level node?
>> > >
>> > > I don’t intend to defend their model, the more serious problem IMO
>>is that a model for a single device/function may be needed in another
>>device that hosts many virtualised devices/functions of the former type.
>>We don’t have a good solution for this rather typical situation.
>> > >
>> > > But a single container called "whatever" provides no such
>>aggregation.
>> > > You would need a list for that. And the NMS might have multiple
>> > > layers of hierarchy to represent various aggregations.  The NP
>> > > container called "device" is not helpful for aggregation.
>> > 
>> > The parent node can be a list as well. The “root” node would be like
>>a mount point in a Unix filesystem.
>> > 
>> > 
>> > Are you saying all data on a device needs to be in a top-level list
>>called 'device'
>> > because an NMS might exist that  wants to have the datastores from
>>lots of devices?
>> > As Martin pointed out several times, the NMS can make its own
>>container or
>> > lists.  It does not need the device to mirror its own structure.
>> 
>> As I said, I don’t care that much about the “device” container. What
>>would be really useful is to have the possibility to do e.g. this:
>> 
>> virtual-node* [name]
>> name
>> if:interfaces
>> ...
>> 
>> to support the use case where all virtual nodes are managed by the same
>>NETCONF/RESTCONF server.
>> 
>> Lada
>> 
>> >  
>> > 
>> > 
>> > Lada
>> > 
>> > Andy
>> >  
>> > 
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > >
>>

Re: [netmod] Y34

[Ladislav Lhotka]

> On 21 Jul 2015, at 09:44, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Jul 21, 2015 at 09:16:46AM +0200, Ladislav Lhotka wrote:
>> 
>>> On 20 Jul 2015, at 23:00, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> Lada,
>>> 
>>> Y34 is closed and I have not seen any new argument here that indicates
>>> we made a major mistake with the resolution of Y34. As such, Y34
>>> remains closed.
>> 
>> Of course, I was expecting this reaction. I think I did present *some* 
>> arguments, and I am leaving it to others to judge whether they are relevant 
>> or not. Even if it was a minor mistake, it is IMO still worth fixing.
>> 
>>> 
>>> If you want to discuss new ideas to relocate or "symlink" data models,
>>> please do so in a separate thread. (And no, we do not accept new
>>> issues for YANG 1.1 either at this point in time.)
>> 
>> It’s not about symlinks in the data tree but rather about a method for 
>> combining schemas that is complementary to “augment” - pull versus push.
>> 
>> There is sufficient evidence that it was one of the use cases for “anydata”, 
>> e.g. in configlets. The gap in “anydata” definition for similar use cases is 
>> that it cannot specify a schema for its contents.
>> 
> 
> 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. And Y34 was not trying to solve this

This is a fair point but “anydata” where the schema is supplied somehow out of 
band faces the same issue.

Lada

> problem, so this discussion is IMHO under a misleading subject line.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Juergen Schoenwaelder]

On Tue, Jul 21, 2015 at 09:16:46AM +0200, Ladislav Lhotka wrote:
> 
> > On 20 Jul 2015, at 23:00, Juergen Schoenwaelder 
> >  wrote:
> > 
> > Lada,
> > 
> > Y34 is closed and I have not seen any new argument here that indicates
> > we made a major mistake with the resolution of Y34. As such, Y34
> > remains closed.
> 
> Of course, I was expecting this reaction. I think I did present *some* 
> arguments, and I am leaving it to others to judge whether they are relevant 
> or not. Even if it was a minor mistake, it is IMO still worth fixing.
> 
> > 
> > If you want to discuss new ideas to relocate or "symlink" data models,
> > please do so in a separate thread. (And no, we do not accept new
> > issues for YANG 1.1 either at this point in time.)
> 
> It’s not about symlinks in the data tree but rather about a method for 
> combining schemas that is complementary to “augment” - pull versus push.
> 
> There is sufficient evidence that it was one of the use cases for “anydata”, 
> e.g. in configlets. The gap in “anydata” definition for similar use cases is 
> that it cannot specify a schema for its contents.
>

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. And Y34 was not trying to solve this
problem, so this discussion is IMHO under a misleading subject line.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Ladislav Lhotka]

> On 20 Jul 2015, at 23:00, Juergen Schoenwaelder 
>  wrote:
> 
> Lada,
> 
> Y34 is closed and I have not seen any new argument here that indicates
> we made a major mistake with the resolution of Y34. As such, Y34
> remains closed.

Of course, I was expecting this reaction. I think I did present *some* 
arguments, and I am leaving it to others to judge whether they are relevant or 
not. Even if it was a minor mistake, it is IMO still worth fixing.

> 
> If you want to discuss new ideas to relocate or "symlink" data models,
> please do so in a separate thread. (And no, we do not accept new
> issues for YANG 1.1 either at this point in time.)

It’s not about symlinks in the data tree but rather about a method for 
combining schemas that is complementary to “augment” - pull versus push.

There is sufficient evidence that it was one of the use cases for “anydata”, 
e.g. in configlets. The gap in “anydata” definition for similar use cases is 
that it cannot specify a schema for its contents.

Lada 

> 
> /js
> 
> On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
>> 
>>> On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
>>> 
>>> 
>>> 
>>> On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka  wrote:
>>> 
 On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
 
 
 
 On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka  wrote:
 
> On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> 
> Hi,
> 
> Can you explain why we need 2 broken anyxmls?
> (The original and a synonym?)  The whole point of
> anydata is that it does not have XML cruft in it.
 
 Yes, I understand this was your main priority. For implementors using 
 off-the-shelf XML parsers and tools the XML cruft is not an issue at all.
 
 
 yes it is an issue.
 We need something to model a container full of arbitrary YANG data nodes.
 This is something that can be applied to the contents of a datastore.
>>> 
>>> anyxml can do that, too.
>>> 
>>> 
>>> the WG already decided it can't.
>>> The extra XML PIs, etc. are not accepted by all servers, remember?
>>> There is no use for the extra stuff in the datastore.
>>> I don't see why we need 2 anyxml constructs that are not
>>> supported by the industry.  One is already too many.
>> 
>> I agree, but this is what we are going to have. My proposal was to have just 
>> one with two different names.
>> 
>>> 
>>> 
 
 
 Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with 
 no (YANG) schema available. My only complaint to “anyxml” has always been 
 that it is a misnomer for encodings other than XML.
 
 The message encoding on the wire is not the same issue
 as the contents of a datastore.  Our server stores its own
 internal data structures.  XML, JSON, CBOR are just message
 encoding formats between client and server.  The datastore
 is not encoded in any of these formats.
>>> 
>>> The payload of anyxml needn’t directly map to a data subtree in the usual 
>>> sense.
>>> 
>>> that's precisely the difference between anyxml and anydata.
>>> The anydata node MUST map directly into data subtrees.
>> 
>> If the server doesn’t know the YANG data model at run time (which is 
>> possible) then it cannot do it - for instance, it cannot properly map module 
>> names to namespace URI or handle lists.
>> 
>>> 
>>> 
>>> 
 
 
 
 
 
> 
> I also don't get the value of a single top-level node called 'device'
> that every YANG model on the planet is supposed to augment.
> Can you explain why a protocol operation to retrieve the
> document root (/) is not sufficient for the top-level node?
 
 I don’t intend to defend their model, the more serious problem IMO is that 
 a model for a single device/function may be needed in another device that 
 hosts many virtualised devices/functions of the former type. We don’t have 
 a good solution for this rather typical situation.
 
 But a single container called "whatever" provides no such aggregation.
 You would need a list for that. And the NMS might have multiple
 layers of hierarchy to represent various aggregations.  The NP
 container called "device" is not helpful for aggregation.
>>> 
>>> The parent node can be a list as well. The “root” node would be like a 
>>> mount point in a Unix filesystem.
>>> 
>>> 
>>> Are you saying all data on a device needs to be in a top-level list called 
>>> 'device'
>>> because an NMS might exist that  wants to have the datastores from lots of 
>>> devices?
>>> As Martin pointed out several times, the NMS can make its own container or
>>> lists.  It does not need the device to mirror its own structure.
>> 
>> As I said, I don’t care that much about the “device” container. What would 
>> be really useful is to have the possibility to do e.g. this:
>> 
>> virtual-node* [name]
>>name
>>if:interfaces
>>...
>> 
>> to support the use ca

Re: [netmod] Y34

[Juergen Schoenwaelder]

Lada,

Y34 is closed and I have not seen any new argument here that indicates
we made a major mistake with the resolution of Y34. As such, Y34
remains closed.

If you want to discuss new ideas to relocate or "symlink" data models,
please do so in a separate thread. (And no, we do not accept new
issues for YANG 1.1 either at this point in time.)

/js

On Mon, Jul 20, 2015 at 07:42:49PM +0200, Ladislav Lhotka wrote:
> 
> > On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka  wrote:
> > 
> > > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
> > >
> > >
> > >
> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka  wrote:
> > >
> > > > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> > > >
> > > > Hi,
> > > >
> > > > Can you explain why we need 2 broken anyxmls?
> > > > (The original and a synonym?)  The whole point of
> > > > anydata is that it does not have XML cruft in it.
> > >
> > > Yes, I understand this was your main priority. For implementors using 
> > > off-the-shelf XML parsers and tools the XML cruft is not an issue at all.
> > >
> > >
> > > yes it is an issue.
> > > We need something to model a container full of arbitrary YANG data nodes.
> > > This is something that can be applied to the contents of a datastore.
> > 
> > anyxml can do that, too.
> > 
> > 
> > the WG already decided it can't.
> > The extra XML PIs, etc. are not accepted by all servers, remember?
> > There is no use for the extra stuff in the datastore.
> >  I don't see why we need 2 anyxml constructs that are not
> > supported by the industry.  One is already too many.
> 
> I agree, but this is what we are going to have. My proposal was to have just 
> one with two different names.
> 
> > 
> > 
> > >
> > >
> > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with 
> > > no (YANG) schema available. My only complaint to “anyxml” has always been 
> > > that it is a misnomer for encodings other than XML.
> > >
> > > The message encoding on the wire is not the same issue
> > > as the contents of a datastore.  Our server stores its own
> > > internal data structures.  XML, JSON, CBOR are just message
> > > encoding formats between client and server.  The datastore
> > > is not encoded in any of these formats.
> > 
> > The payload of anyxml needn’t directly map to a data subtree in the usual 
> > sense.
> > 
> > that's precisely the difference between anyxml and anydata.
> > The anydata node MUST map directly into data subtrees.
> 
> If the server doesn’t know the YANG data model at run time (which is 
> possible) then it cannot do it - for instance, it cannot properly map module 
> names to namespace URI or handle lists.
> 
> > 
> >  
> > 
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > I also don't get the value of a single top-level node called 'device'
> > > > that every YANG model on the planet is supposed to augment.
> > > > Can you explain why a protocol operation to retrieve the
> > > > document root (/) is not sufficient for the top-level node?
> > >
> > > I don’t intend to defend their model, the more serious problem IMO is 
> > > that a model for a single device/function may be needed in another device 
> > > that hosts many virtualised devices/functions of the former type. We 
> > > don’t have a good solution for this rather typical situation.
> > >
> > > But a single container called "whatever" provides no such aggregation.
> > > You would need a list for that. And the NMS might have multiple
> > > layers of hierarchy to represent various aggregations.  The NP
> > > container called "device" is not helpful for aggregation.
> > 
> > The parent node can be a list as well. The “root” node would be like a 
> > mount point in a Unix filesystem.
> > 
> > 
> > Are you saying all data on a device needs to be in a top-level list called 
> > 'device'
> > because an NMS might exist that  wants to have the datastores from lots of 
> > devices?
> > As Martin pointed out several times, the NMS can make its own container or
> > lists.  It does not need the device to mirror its own structure.
> 
> As I said, I don’t care that much about the “device” container. What would be 
> really useful is to have the possibility to do e.g. this:
> 
> virtual-node* [name]
> name
> if:interfaces
> ...
> 
> to support the use case where all virtual nodes are managed by the same 
> NETCONF/RESTCONF server.
> 
> Lada
> 
> >  
> > 
> > 
> > Lada
> > 
> > Andy
> >  
> > 
> > >
> > >
> > >
> > > Lada
> > >
> > >
> > > Andy
> > >
> > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka  wrote:
> > > >
> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > after listening to the presentation of
> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> > > > > whether the solution chosen for Y34 is really useful.
> > > > >
> > > > > The draft st

Re: [netmod] Y34

[Ladislav Lhotka]

> On 20 Jul 2015, at 19:29, Andy Bierman  wrote:
> 
> 
> 
> On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka  wrote:
> 
> > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
> >
> >
> >
> > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka  wrote:
> >
> > > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> > >
> > > Hi,
> > >
> > > Can you explain why we need 2 broken anyxmls?
> > > (The original and a synonym?)  The whole point of
> > > anydata is that it does not have XML cruft in it.
> >
> > Yes, I understand this was your main priority. For implementors using 
> > off-the-shelf XML parsers and tools the XML cruft is not an issue at all.
> >
> >
> > yes it is an issue.
> > We need something to model a container full of arbitrary YANG data nodes.
> > This is something that can be applied to the contents of a datastore.
> 
> anyxml can do that, too.
> 
> 
> the WG already decided it can't.
> The extra XML PIs, etc. are not accepted by all servers, remember?
> There is no use for the extra stuff in the datastore.
>  I don't see why we need 2 anyxml constructs that are not
> supported by the industry.  One is already too many.

I agree, but this is what we are going to have. My proposal was to have just 
one with two different names.

> 
> 
> >
> >
> > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no 
> > (YANG) schema available. My only complaint to “anyxml” has always been that 
> > it is a misnomer for encodings other than XML.
> >
> > The message encoding on the wire is not the same issue
> > as the contents of a datastore.  Our server stores its own
> > internal data structures.  XML, JSON, CBOR are just message
> > encoding formats between client and server.  The datastore
> > is not encoded in any of these formats.
> 
> The payload of anyxml needn’t directly map to a data subtree in the usual 
> sense.
> 
> that's precisely the difference between anyxml and anydata.
> The anydata node MUST map directly into data subtrees.

If the server doesn’t know the YANG data model at run time (which is possible) 
then it cannot do it - for instance, it cannot properly map module names to 
namespace URI or handle lists.

> 
>  
> 
> >
> >
> >
> >
> >
> > >
> > > I also don't get the value of a single top-level node called 'device'
> > > that every YANG model on the planet is supposed to augment.
> > > Can you explain why a protocol operation to retrieve the
> > > document root (/) is not sufficient for the top-level node?
> >
> > I don’t intend to defend their model, the more serious problem IMO is that 
> > a model for a single device/function may be needed in another device that 
> > hosts many virtualised devices/functions of the former type. We don’t have 
> > a good solution for this rather typical situation.
> >
> > But a single container called "whatever" provides no such aggregation.
> > You would need a list for that. And the NMS might have multiple
> > layers of hierarchy to represent various aggregations.  The NP
> > container called "device" is not helpful for aggregation.
> 
> The parent node can be a list as well. The “root” node would be like a mount 
> point in a Unix filesystem.
> 
> 
> Are you saying all data on a device needs to be in a top-level list called 
> 'device'
> because an NMS might exist that  wants to have the datastores from lots of 
> devices?
> As Martin pointed out several times, the NMS can make its own container or
> lists.  It does not need the device to mirror its own structure.

As I said, I don’t care that much about the “device” container. What would be 
really useful is to have the possibility to do e.g. this:

virtual-node* [name]
name
if:interfaces
...

to support the use case where all virtual nodes are managed by the same 
NETCONF/RESTCONF server.

Lada

>  
> 
> 
> Lada
> 
> Andy
>  
> 
> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > Andy
> > >
> > >
> > >
> > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka  wrote:
> > >
> > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> > > >
> > > > Hi,
> > > >
> > > > after listening to the presentation of
> > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> > > > whether the solution chosen for Y34 is really useful.
> > > >
> > > > The draft states they want to reuse ietf-interfaces but their tree in
> > > > fact is
> > > >
> > > >   +--rw device
> > > >  +--rw info
> > > >  |  +--rw device-type?   enumeration
> > > >  +--rw hardware
> > > >  +--rw interfaces
> > > >  |  +--rw interface* [name]
> > > >  | ...
> > > >  +--rw qos
> > > >
> > > > So the "interfaces" container is no more a top-level node. There are
> > > > three possible options:
> > > >
> > > > 1. Change the ietf-interfaces module.
> > > > 2. Replicate its contents in another module.
> > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a
> > > >   given data node.
> > > >
> > > > IMO #1 & #2 are r

Re: [netmod] Y34

[Andy Bierman]

On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka  wrote:

>
> > On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
> >
> >
> >
> > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka  wrote:
> >
> > > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> > >
> > > Hi,
> > >
> > > Can you explain why we need 2 broken anyxmls?
> > > (The original and a synonym?)  The whole point of
> > > anydata is that it does not have XML cruft in it.
> >
> > Yes, I understand this was your main priority. For implementors using
> off-the-shelf XML parsers and tools the XML cruft is not an issue at all.
> >
> >
> > yes it is an issue.
> > We need something to model a container full of arbitrary YANG data nodes.
> > This is something that can be applied to the contents of a datastore.
>
> anyxml can do that, too.
>


the WG already decided it can't.
The extra XML PIs, etc. are not accepted by all servers, remember?
There is no use for the extra stuff in the datastore.
 I don't see why we need 2 anyxml constructs that are not
supported by the industry.  One is already too many.


> >
> >
> > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with
> no (YANG) schema available. My only complaint to “anyxml” has always been
> that it is a misnomer for encodings other than XML.
> >
> > The message encoding on the wire is not the same issue
> > as the contents of a datastore.  Our server stores its own
> > internal data structures.  XML, JSON, CBOR are just message
> > encoding formats between client and server.  The datastore
> > is not encoded in any of these formats.
>
> The payload of anyxml needn’t directly map to a data subtree in the usual
> sense.
>

that's precisely the difference between anyxml and anydata.
The anydata node MUST map directly into data subtrees.



>
> >
> >
> >
> >
> >
> > >
> > > I also don't get the value of a single top-level node called 'device'
> > > that every YANG model on the planet is supposed to augment.
> > > Can you explain why a protocol operation to retrieve the
> > > document root (/) is not sufficient for the top-level node?
> >
> > I don’t intend to defend their model, the more serious problem IMO is
> that a model for a single device/function may be needed in another device
> that hosts many virtualised devices/functions of the former type. We don’t
> have a good solution for this rather typical situation.
> >
> > But a single container called "whatever" provides no such aggregation.
> > You would need a list for that. And the NMS might have multiple
> > layers of hierarchy to represent various aggregations.  The NP
> > container called "device" is not helpful for aggregation.
>
> The parent node can be a list as well. The “root” node would be like a
> mount point in a Unix filesystem.
>
>
Are you saying all data on a device needs to be in a top-level list called
'device'
because an NMS might exist that  wants to have the datastores from lots of
devices?
As Martin pointed out several times, the NMS can make its own container or
lists.  It does not need the device to mirror its own structure.


Lada
>

Andy


>
> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > Andy
> > >
> > >
> > >
> > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka 
> wrote:
> > >
> > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> > > >
> > > > Hi,
> > > >
> > > > after listening to the presentation of
> > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am
> wondering
> > > > whether the solution chosen for Y34 is really useful.
> > > >
> > > > The draft states they want to reuse ietf-interfaces but their tree in
> > > > fact is
> > > >
> > > >   +--rw device
> > > >  +--rw info
> > > >  |  +--rw device-type?   enumeration
> > > >  +--rw hardware
> > > >  +--rw interfaces
> > > >  |  +--rw interface* [name]
> > > >  | ...
> > > >  +--rw qos
> > > >
> > > > So the "interfaces" container is no more a top-level node. There are
> > > > three possible options:
> > > >
> > > > 1. Change the ietf-interfaces module.
> > > > 2. Replicate its contents in another module.
> > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a
> > > >   given data node.
> > > >
> > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but
> it
> > > > seems it is not so because it doesn't specify a concrete data model
> > > > that's allowed at a given location.
> > > >
> > > > On the other hand, the only real contribution of "anydata" over
> "anyxml"
> > > > is that is doesn't permit mixed content in XML, which is IMO not
> much.
> > > >
> > > > I know Y34 was already closed but I think it is more important to do
> > > > things right before YANG 1.1 becomes an RFC.
> > > >
> > > > What I want to propose is this:
> > > >
> > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml"
> (but
> > > >  keep it for backward compatibility).
> > >
> > > s/Rename/Introduce/
> > >
> > > >
> > > > - Introduce a ne

Re: [netmod] Y34

[Ladislav Lhotka]

> On 20 Jul 2015, at 17:00, Andy Bierman  wrote:
> 
> 
> 
> On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka  wrote:
> 
> > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> >
> > Hi,
> >
> > Can you explain why we need 2 broken anyxmls?
> > (The original and a synonym?)  The whole point of
> > anydata is that it does not have XML cruft in it.
> 
> Yes, I understand this was your main priority. For implementors using 
> off-the-shelf XML parsers and tools the XML cruft is not an issue at all.
> 
> 
> yes it is an issue.
> We need something to model a container full of arbitrary YANG data nodes.
> This is something that can be applied to the contents of a datastore.

anyxml can do that, too.

> 
>  
> Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no 
> (YANG) schema available. My only complaint to “anyxml” has always been that 
> it is a misnomer for encodings other than XML.
> 
> The message encoding on the wire is not the same issue
> as the contents of a datastore.  Our server stores its own
> internal data structures.  XML, JSON, CBOR are just message
> encoding formats between client and server.  The datastore
> is not encoded in any of these formats.

The payload of anyxml needn’t directly map to a data subtree in the usual sense.

> 
> 
> 
>  
> 
> >
> > I also don't get the value of a single top-level node called 'device'
> > that every YANG model on the planet is supposed to augment.
> > Can you explain why a protocol operation to retrieve the
> > document root (/) is not sufficient for the top-level node?
> 
> I don’t intend to defend their model, the more serious problem IMO is that a 
> model for a single device/function may be needed in another device that hosts 
> many virtualised devices/functions of the former type. We don’t have a good 
> solution for this rather typical situation.
> 
> But a single container called "whatever" provides no such aggregation.
> You would need a list for that. And the NMS might have multiple
> layers of hierarchy to represent various aggregations.  The NP
> container called "device" is not helpful for aggregation.

The parent node can be a list as well. The “root” node would be like a mount 
point in a Unix filesystem.

Lada

> 
> 
> 
> Lada
> 
> 
> Andy
>  
> 
> >
> > Andy
> >
> >
> >
> > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka  wrote:
> >
> > > On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> > >
> > > Hi,
> > >
> > > after listening to the presentation of
> > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> > > whether the solution chosen for Y34 is really useful.
> > >
> > > The draft states they want to reuse ietf-interfaces but their tree in
> > > fact is
> > >
> > >   +--rw device
> > >  +--rw info
> > >  |  +--rw device-type?   enumeration
> > >  +--rw hardware
> > >  +--rw interfaces
> > >  |  +--rw interface* [name]
> > >  | ...
> > >  +--rw qos
> > >
> > > So the "interfaces" container is no more a top-level node. There are
> > > three possible options:
> > >
> > > 1. Change the ietf-interfaces module.
> > > 2. Replicate its contents in another module.
> > > 3. Extend YANG so that a *specific* schema tree can be grafted at a
> > >   given data node.
> > >
> > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it
> > > seems it is not so because it doesn't specify a concrete data model
> > > that's allowed at a given location.
> > >
> > > On the other hand, the only real contribution of "anydata" over "anyxml"
> > > is that is doesn't permit mixed content in XML, which is IMO not much.
> > >
> > > I know Y34 was already closed but I think it is more important to do
> > > things right before YANG 1.1 becomes an RFC.
> > >
> > > What I want to propose is this:
> > >
> > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but
> > >  keep it for backward compatibility).
> >
> > s/Rename/Introduce/
> >
> > >
> > > - Introduce a new statement and data node type, e.g. "root", that will
> > >  extend the schema tree starting from that data node with a precisely
> > >  specified data model. The specification can be same or similar as
> > >  in yang-library.
> > >
> > > I believe there are other use cases in the existing modules. For
> > > example, the ietf-routing module could simply define the data model for
> > > a single routing instance (i.e. without "routing-instance" list at the
> > > top), and it can be then used without changes on simple devices, and
> > > more complex router implementations can graft it as a subtree under
> > > "routing-instance", "networking-instance" or whatever.
> > >
> > > Lada
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E7

Re: [netmod] Y34

[Andy Bierman]

On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka  wrote:

>
> > On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> >
> > Hi,
> >
> > Can you explain why we need 2 broken anyxmls?
> > (The original and a synonym?)  The whole point of
> > anydata is that it does not have XML cruft in it.
>
> Yes, I understand this was your main priority. For implementors using
> off-the-shelf XML parsers and tools the XML cruft is not an issue at all.
>
>
yes it is an issue.
We need something to model a container full of arbitrary YANG data nodes.
This is something that can be applied to the contents of a datastore.



> Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with
> no (YANG) schema available. My only complaint to “anyxml” has always been
> that it is a misnomer for encodings other than XML.
>

The message encoding on the wire is not the same issue
as the contents of a datastore.  Our server stores its own
internal data structures.  XML, JSON, CBOR are just message
encoding formats between client and server.  The datastore
is not encoded in any of these formats.





>
> >
> > I also don't get the value of a single top-level node called 'device'
> > that every YANG model on the planet is supposed to augment.
> > Can you explain why a protocol operation to retrieve the
> > document root (/) is not sufficient for the top-level node?
>
> I don’t intend to defend their model, the more serious problem IMO is that
> a model for a single device/function may be needed in another device that
> hosts many virtualised devices/functions of the former type. We don’t have
> a good solution for this rather typical situation.
>

But a single container called "whatever" provides no such aggregation.
You would need a list for that. And the NMS might have multiple
layers of hierarchy to represent various aggregations.  The NP
container called "device" is not helpful for aggregation.



> Lada
>


Andy


>
> >
> > Andy
> >
> >
> >
> > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka  wrote:
> >
> > > On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> > >
> > > Hi,
> > >
> > > after listening to the presentation of
> > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> > > whether the solution chosen for Y34 is really useful.
> > >
> > > The draft states they want to reuse ietf-interfaces but their tree in
> > > fact is
> > >
> > >   +--rw device
> > >  +--rw info
> > >  |  +--rw device-type?   enumeration
> > >  +--rw hardware
> > >  +--rw interfaces
> > >  |  +--rw interface* [name]
> > >  | ...
> > >  +--rw qos
> > >
> > > So the "interfaces" container is no more a top-level node. There are
> > > three possible options:
> > >
> > > 1. Change the ietf-interfaces module.
> > > 2. Replicate its contents in another module.
> > > 3. Extend YANG so that a *specific* schema tree can be grafted at a
> > >   given data node.
> > >
> > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it
> > > seems it is not so because it doesn't specify a concrete data model
> > > that's allowed at a given location.
> > >
> > > On the other hand, the only real contribution of "anydata" over
> "anyxml"
> > > is that is doesn't permit mixed content in XML, which is IMO not much.
> > >
> > > I know Y34 was already closed but I think it is more important to do
> > > things right before YANG 1.1 becomes an RFC.
> > >
> > > What I want to propose is this:
> > >
> > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml"
> (but
> > >  keep it for backward compatibility).
> >
> > s/Rename/Introduce/
> >
> > >
> > > - Introduce a new statement and data node type, e.g. "root", that will
> > >  extend the schema tree starting from that data node with a precisely
> > >  specified data model. The specification can be same or similar as
> > >  in yang-library.
> > >
> > > I believe there are other use cases in the existing modules. For
> > > example, the ietf-routing module could simply define the data model for
> > > a single routing instance (i.e. without "routing-instance" list at the
> > > top), and it can be then used without changes on simple devices, and
> > > more complex router implementations can graft it as a subtree under
> > > "routing-instance", "networking-instance" or whatever.
> > >
> > > Lada
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ie

Re: [netmod] Y34

[Ladislav Lhotka]

> On 20 Jul 2015, at 14:55, Andy Bierman  wrote:
> 
> Hi,
> 
> Can you explain why we need 2 broken anyxmls?
> (The original and a synonym?)  The whole point of
> anydata is that it does not have XML cruft in it.

Yes, I understand this was your main priority. For implementors using 
off-the-shelf XML parsers and tools the XML cruft is not an issue at all.

Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no 
(YANG) schema available. My only complaint to “anyxml” has always been that it 
is a misnomer for encodings other than XML.

> 
> I also don't get the value of a single top-level node called 'device'
> that every YANG model on the planet is supposed to augment.
> Can you explain why a protocol operation to retrieve the
> document root (/) is not sufficient for the top-level node?

I don’t intend to defend their model, the more serious problem IMO is that a 
model for a single device/function may be needed in another device that hosts 
many virtualised devices/functions of the former type. We don’t have a good 
solution for this rather typical situation.

Lada

> 
> Andy
> 
> 
> 
> On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka  wrote:
> 
> > On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> >
> > Hi,
> >
> > after listening to the presentation of
> > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> > whether the solution chosen for Y34 is really useful.
> >
> > The draft states they want to reuse ietf-interfaces but their tree in
> > fact is
> >
> >   +--rw device
> >  +--rw info
> >  |  +--rw device-type?   enumeration
> >  +--rw hardware
> >  +--rw interfaces
> >  |  +--rw interface* [name]
> >  | ...
> >  +--rw qos
> >
> > So the "interfaces" container is no more a top-level node. There are
> > three possible options:
> >
> > 1. Change the ietf-interfaces module.
> > 2. Replicate its contents in another module.
> > 3. Extend YANG so that a *specific* schema tree can be grafted at a
> >   given data node.
> >
> > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it
> > seems it is not so because it doesn't specify a concrete data model
> > that's allowed at a given location.
> >
> > On the other hand, the only real contribution of "anydata" over "anyxml"
> > is that is doesn't permit mixed content in XML, which is IMO not much.
> >
> > I know Y34 was already closed but I think it is more important to do
> > things right before YANG 1.1 becomes an RFC.
> >
> > What I want to propose is this:
> >
> > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but
> >  keep it for backward compatibility).
> 
> s/Rename/Introduce/
> 
> >
> > - Introduce a new statement and data node type, e.g. "root", that will
> >  extend the schema tree starting from that data node with a precisely
> >  specified data model. The specification can be same or similar as
> >  in yang-library.
> >
> > I believe there are other use cases in the existing modules. For
> > example, the ietf-routing module could simply define the data model for
> > a single routing instance (i.e. without "routing-instance" list at the
> > top), and it can be then used without changes on simple devices, and
> > more complex router implementations can graft it as a subtree under
> > "routing-instance", "networking-instance" or whatever.
> >
> > Lada
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Andy Bierman]

Hi,

Can you explain why we need 2 broken anyxmls?
(The original and a synonym?)  The whole point of
anydata is that it does not have XML cruft in it.

I also don't get the value of a single top-level node called 'device'
that every YANG model on the planet is supposed to augment.
Can you explain why a protocol operation to retrieve the
document root (/) is not sufficient for the top-level node?

Andy



On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka  wrote:

>
> > On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> >
> > Hi,
> >
> > after listening to the presentation of
> > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> > whether the solution chosen for Y34 is really useful.
> >
> > The draft states they want to reuse ietf-interfaces but their tree in
> > fact is
> >
> >   +--rw device
> >  +--rw info
> >  |  +--rw device-type?   enumeration
> >  +--rw hardware
> >  +--rw interfaces
> >  |  +--rw interface* [name]
> >  | ...
> >  +--rw qos
> >
> > So the "interfaces" container is no more a top-level node. There are
> > three possible options:
> >
> > 1. Change the ietf-interfaces module.
> > 2. Replicate its contents in another module.
> > 3. Extend YANG so that a *specific* schema tree can be grafted at a
> >   given data node.
> >
> > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it
> > seems it is not so because it doesn't specify a concrete data model
> > that's allowed at a given location.
> >
> > On the other hand, the only real contribution of "anydata" over "anyxml"
> > is that is doesn't permit mixed content in XML, which is IMO not much.
> >
> > I know Y34 was already closed but I think it is more important to do
> > things right before YANG 1.1 becomes an RFC.
> >
> > What I want to propose is this:
> >
> > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but
> >  keep it for backward compatibility).
>
> s/Rename/Introduce/
>
> >
> > - Introduce a new statement and data node type, e.g. "root", that will
> >  extend the schema tree starting from that data node with a precisely
> >  specified data model. The specification can be same or similar as
> >  in yang-library.
> >
> > I believe there are other use cases in the existing modules. For
> > example, the ietf-routing module could simply define the data model for
> > a single routing instance (i.e. without "routing-instance" list at the
> > top), and it can be then used without changes on simple devices, and
> > more complex router implementations can graft it as a subtree under
> > "routing-instance", "networking-instance" or whatever.
> >
> > Lada
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34

[Ladislav Lhotka]

> On 20 Jul 2015, at 14:45, Ladislav Lhotka  wrote:
> 
> Hi,
> 
> after listening to the presentation of
> draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
> whether the solution chosen for Y34 is really useful.
> 
> The draft states they want to reuse ietf-interfaces but their tree in
> fact is
> 
>   +--rw device
>  +--rw info
>  |  +--rw device-type?   enumeration
>  +--rw hardware
>  +--rw interfaces
>  |  +--rw interface* [name]
>  | ...
>  +--rw qos
> 
> So the "interfaces" container is no more a top-level node. There are
> three possible options:
> 
> 1. Change the ietf-interfaces module.
> 2. Replicate its contents in another module.
> 3. Extend YANG so that a *specific* schema tree can be grafted at a
>   given data node.
> 
> IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it
> seems it is not so because it doesn't specify a concrete data model
> that's allowed at a given location.
> 
> On the other hand, the only real contribution of "anydata" over "anyxml"
> is that is doesn't permit mixed content in XML, which is IMO not much.
> 
> I know Y34 was already closed but I think it is more important to do
> things right before YANG 1.1 becomes an RFC.
> 
> What I want to propose is this:
> 
> - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but
>  keep it for backward compatibility).

s/Rename/Introduce/

> 
> - Introduce a new statement and data node type, e.g. "root", that will
>  extend the schema tree starting from that data node with a precisely
>  specified data model. The specification can be same or similar as
>  in yang-library.
> 
> I believe there are other use cases in the existing modules. For
> example, the ietf-routing module could simply define the data model for
> a single routing instance (i.e. without "routing-instance" list at the
> top), and it can be then used without changes on simple devices, and
> more complex router implementations can graft it as a subtree under
> "routing-instance", "networking-instance" or whatever.
> 
> Lada
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Y34

[Ladislav Lhotka]

Hi,

after listening to the presentation of
draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering
whether the solution chosen for Y34 is really useful.

The draft states they want to reuse ietf-interfaces but their tree in
fact is

   +--rw device
  +--rw info
  |  +--rw device-type?   enumeration
  +--rw hardware
  +--rw interfaces
  |  +--rw interface* [name]
  | ...
  +--rw qos

So the "interfaces" container is no more a top-level node. There are
three possible options:

1. Change the ietf-interfaces module.
2. Replicate its contents in another module.
3. Extend YANG so that a *specific* schema tree can be grafted at a
   given data node.

IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it
seems it is not so because it doesn't specify a concrete data model
that's allowed at a given location.

On the other hand, the only real contribution of "anydata" over "anyxml"
is that is doesn't permit mixed content in XML, which is IMO not much.

I know Y34 was already closed but I think it is more important to do
things right before YANG 1.1 becomes an RFC.

What I want to propose is this:

- Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but
  keep it for backward compatibility).

- Introduce a new statement and data node type, e.g. "root", that will
  extend the schema tree starting from that data node with a precisely
  specified data model. The specification can be same or similar as
  in yang-library.

I believe there are other use cases in the existing modules. For
example, the ietf-routing module could simply define the data model for
a single routing instance (i.e. without "routing-instance" list at the
top), and it can be then used without changes on simple devices, and
more complex router implementations can graft it as a subtree under
"routing-instance", "networking-instance" or whatever.

Lada

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod