Re: [netmod] Y34 - root node
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
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) a...@cisco.com Cc: lho...@nic.cz; netmod@ietf.org Subject: Re: [netmod] Y34 - root node Alexander Clemm (alex) a...@cisco.com 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) a...@cisco.com 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
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
On Wed, Aug 26, 2015 at 9:41 AM, t.petch ie...@btconnect.com wrote: - Original Message - From: Juergen Schoenwaelder j.schoenwael...@jacobs-university.de To: t. petch ie...@btconnect.com Cc: rwil...@cisco.com; Martin Bjorklund m...@tail-f.com; netmod@ietf.org 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 http://www.jacobs-university.de/ ___ 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
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
From: Andy Bierman, Friday, August 21, 2015 10:28 AM snip 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
Robert Wilton rwil...@cisco.com wrote:
Hi Martin,
On 20/08/2015 09:15, Martin Bjorklund wrote:
Andy Bierman a...@yumaworks.com wrote:
On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund m...@tail-f.com
wrote:
Robert Wilton rwil...@cisco.com 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/device-name/interfaces/interface?
Ideally, they would be able to use the same YANG definitions that
are defined for /interfaces/ but root them relative to
/network/device/device-name/.
Yes -- some of us (like Martin) have pointed this out many times.
The device container on an NE does not help at all wrt/
aggregation on a controller. /device or / work the same for this
purpose.
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/device-name/interfaces/interface be?
I don't think there is such a thing as a real location. The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of relocating YANG modules, and
ODL has its mount, and I think Andy has some other mechanism. Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
+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
Re: [netmod] Y34 - root node
On Fri, Aug 21, 2015 at 6:01 AM, Martin Bjorklund m...@tail-f.com wrote:
Robert Wilton rwil...@cisco.com wrote:
Hi Martin,
On 20/08/2015 09:15, Martin Bjorklund wrote:
Andy Bierman a...@yumaworks.com wrote:
On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund m...@tail-f.com
wrote:
Robert Wilton rwil...@cisco.com 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/device-name/interfaces/interface?
Ideally, they would be able to use the same YANG definitions
that
are defined for /interfaces/ but root them relative to
/network/device/device-name/.
Yes -- some of us (like Martin) have pointed this out many times.
The device container on an NE does not help at all wrt/
aggregation on a controller. /device or / work the same for
this
purpose.
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/device-name/interfaces/interface be?
I don't think there is such a thing as a real location. The path
is
scoped in the system you work with; in the controller it might be as
I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of relocating YANG modules, and
ODL has its mount, and I think Andy has some other mechanism.
Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
+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
Re: [netmod] Y34 - root node
On 21 Aug 2015, at 15:01, Martin Bjorklund m...@tail-f.com wrote:
Robert Wilton rwil...@cisco.com wrote:
Hi Martin,
On 20/08/2015 09:15, Martin Bjorklund wrote:
Andy Bierman a...@yumaworks.com wrote:
On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund m...@tail-f.com
wrote:
Robert Wilton rwil...@cisco.com 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/device-name/interfaces/interface?
Ideally, they would be able to use the same YANG definitions that
are defined for /interfaces/ but root them relative to
/network/device/device-name/.
Yes -- some of us (like Martin) have pointed this out many times.
The device container on an NE does not help at all wrt/
aggregation on a controller. /device or / work the same for this
purpose.
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/device-name/interfaces/interface be?
I don't think there is such a thing as a real location. The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of relocating YANG modules, and
ODL has its mount, and I think Andy has some other mechanism. Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
+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
Re: [netmod] Y34 - root node
Hi Martin,
On 20/08/2015 09:15, Martin Bjorklund wrote:
Andy Bierman a...@yumaworks.com wrote:
On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund m...@tail-f.com wrote:
Robert Wilton rwil...@cisco.com 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/device-name/interfaces/interface?
Ideally, they would be able to use the same YANG definitions that
are defined for /interfaces/ but root them relative to
/network/device/device-name/.
Yes -- some of us (like Martin) have pointed this out many times.
The device container on an NE does not help at all wrt/
aggregation on a controller. /device or / work the same for this
purpose.
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/device-name/interfaces/interface be?
I don't think there is such a thing as a real location. The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of relocating YANG modules, and
ODL has its mount, and I think Andy has some other mechanism. Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
+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
Re: [netmod] Y34 - root node
Andy Bierman a...@yumaworks.com writes:
On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund m...@tail-f.com wrote:
Robert Wilton rwil...@cisco.com 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/device-name/interfaces/interface?
Ideally, they would be able to use the same YANG definitions that
are defined for /interfaces/ but root them relative to
/network/device/device-name/.
Yes -- some of us (like Martin) have pointed this out many times.
The device container on an NE does not help at all wrt/
aggregation on a controller. /device or / work the same for this
purpose.
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/device-name/interfaces/interface be?
I don't think there is such a thing as a real location. The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of relocating YANG modules, and
ODL has its mount, and I think Andy has some other mechanism. Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
+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
Andy Bierman a...@yumaworks.com wrote:
On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund m...@tail-f.com wrote:
Robert Wilton rwil...@cisco.com 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/device-name/interfaces/interface?
Ideally, they would be able to use the same YANG definitions that
are defined for /interfaces/ but root them relative to
/network/device/device-name/.
Yes -- some of us (like Martin) have pointed this out many times.
The device container on an NE does not help at all wrt/
aggregation on a controller. /device or / work the same for this
purpose.
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/device-name/interfaces/interface be?
I don't think there is such a thing as a real location. The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of relocating YANG modules, and
ODL has its mount, and I think Andy has some other mechanism. Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
+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
Robert Wilton rwil...@cisco.com 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/device-name/interfaces/interface?
Ideally, they would be able to use the same YANG definitions that
are defined for /interfaces/ but root them relative to
/network/device/device-name/.
Yes -- some of us (like Martin) have pointed this out many times.
The device container on an NE does not help at all wrt/
aggregation on a controller. /device or / work the same for this
purpose.
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/device-name/interfaces/interface be?
I don't think there is such a thing as a real location. The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of relocating YANG modules, and
ODL has its mount, and I think Andy has some other mechanism. Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y34 - root node
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/device-name/interfaces/interface? Ideally, they would be able to use the same YANG definitions that are defined for /interfaces/ but root them relative to /network/device/device-name/. Yes -- some of us (like Martin) have pointed this out many times. The device container on an NE does not help at all wrt/ aggregation on a controller. /device or / work the same for this purpose. 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/device-name/interfaces/interface be? If the concrete location for all interfaces (regardless of device) was the flat list /interfaces/ then you would get clashes between the names of the interfaces on different devices. Also, what if someone wanted two separate lists of interfaces in two separate parts of the resource hierarchy. Would that be feasible? Thanks, Rob Cheers, Rob Andy Lada Thanks, Acee Andy From: netmod netmod-boun...@ietf.org mailto:netmod-boun...@ietf.org on behalf of Einar Nilsen-Nygaard (einarnn) eina...@cisco.com mailto:eina...@cisco.com Date: Monday, August 10, 2015 at 5:29 AM To: Jonathan Hansford jonat...@hansfords.net mailto:jonat...@hansfords.net Cc: NETMOD Working Group netmod@ietf.org 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 jonat...@hansfords.net 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) eina...@cisco.com mailto:eina...@cisco.com To: Andy Bierman a...@yumaworks.com mailto:a...@yumaworks.com Cc: NETMOD Working Group netmod@ietf.org mailto:netmod@ietf.org Sent: Sat, 8 Aug 2015 11:10:15 + Subject
Re: [netmod] Y34 - root node
On 11/08/2015 08:38, Ladislav Lhotka wrote: On 10 Aug 2015, at 22:15, Andy Bierman a...@yumaworks.com wrote: On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) 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? 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/device-name/interfaces/interface? Ideally, they would be able to use the same YANG definitions that are defined for /interfaces/ but root them relative to /network/device/device-name/. Having YANG packages being able to control the relative paths of the imported YANG modules would possibly allow for more flexibility in how YANG modules fit together, and also give a more pragmatic way for how these could be changed/upgraded in future if necessary. Cheers, Rob Lada Thanks, Acee Andy From: netmod netmod-boun...@ietf.org on behalf of Einar Nilsen-Nygaard (einarnn) eina...@cisco.com Date: Monday, August 10, 2015 at 5:29 AM To: Jonathan Hansford jonat...@hansfords.net Cc: NETMOD Working Group 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 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) eina...@cisco.com To: Andy Bierman a...@yumaworks.com Cc: NETMOD Working Group 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 a...@yumaworks.com wrote
Re: [netmod] Y34 - root node
On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton rwil...@cisco.com wrote: On 11/08/2015 08:38, Ladislav Lhotka wrote: On 10 Aug 2015, at 22:15, Andy Bierman a...@yumaworks.com wrote: On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) 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? 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/device-name/interfaces/interface? Ideally, they would be able to use the same YANG definitions that are defined for /interfaces/ but root them relative to /network/device/device-name/. Yes -- some of us (like Martin) have pointed this out many times. The device container on an NE does not help at all wrt/ aggregation on a controller. /device or / work the same for this purpose. 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. Cheers, Rob Andy Lada Thanks, Acee Andy From: netmod netmod-boun...@ietf.org on behalf of Einar Nilsen-Nygaard (einarnn) eina...@cisco.com Date: Monday, August 10, 2015 at 5:29 AM To: Jonathan Hansford jonat...@hansfords.net Cc: NETMOD Working Group 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
Re: [netmod] Y34 - root node
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 rwil...@cisco.com 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
On 10 Aug 2015, at 22:15, Andy Bierman a...@yumaworks.com wrote: On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) 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? 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 netmod-boun...@ietf.org on behalf of Einar Nilsen-Nygaard (einarnn) eina...@cisco.com Date: Monday, August 10, 2015 at 5:29 AM To: Jonathan Hansford jonat...@hansfords.net Cc: NETMOD Working Group 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 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) eina...@cisco.com To: Andy Bierman a...@yumaworks.com Cc: NETMOD Working Group 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 a...@yumaworks.com wrote: On Tue, Aug 4, 2015 at 2:34 AM, t.petch ie...@btconnect.com wrote: - Original Message - From: Andy Bierman a...@yumaworks.com To: t.petch ie...@btconnect.com Sent: Monday, August 03, 2015 5:17 PM - Original Message - From: Andy Bierman andy@yumaworkscom To: t.petch 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) 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
Re: [netmod] Y34 - root node
- Original Message - From: Jonathan Hansford jonat...@hansfords.net cc: NETMOD Working Group netmod@ietf.org 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. tp History suggests otherwise to me. If you look at the evolution of standard modules, such as routing and interfaces, that suggests that those who have been immersed in YANG since NGO make several u-turns on the way to where we now are, which may or may not be the end point. You could also look at 6087 or 6087bis which are extensive but perhaps not comprehensive. Tom Petch But coming to it cold (in the sense of 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. 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
Re: [netmod] Y34 - root node
On Mon, Aug 10, 2015 at 1:46 AM, Jonathan Hansford 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). IMO you are describing a different problem. Certainly YANG authors need to know how to use YANG most effectively. A separate problem is the ease of use of YANG module implementations within NETCONF or RESTCONF servers by operators. The current answer is (a) proprietary tool magic or (b) read every single YANG module very carefully and then all the vendor documentation. Then study the server module advertisements to plug in all the features, revisions, and deviations. The resource directory approach and YANG package approach are complimentary. It is useful to know that a get on /services/routing will return the location of routing data. It is also useful to know in advance what modules are used for routing in each server. The location of actual resources should not be hard-wired and brittle. We should learn from HTTP how to manage resources without hard-wiring the paths to resources. Jonathan Andy - Original Message - From: Einar Nilsen-Nygaard (einarnn) eina...@cisco.com To: Andy Bierman a...@yumaworks.com Cc: NETMOD Working Group 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 a...@yumaworks.com wrote: On Tue, Aug 4, 2015 at 2:34 AM, t.petch ie...@btconnect.com wrote: - Original Message - From: Andy Bierman a...@yumaworks.com To: t.petch ie...@btconnect.com Sent: Monday, August 03, 2015 5:17 PM - Original Message - From: Andy Bierman andy@yumaworkscom a...@yumaworks.com To: t.petch 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) 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. tp One aspect of YANG I have never grasped is what a root means, if anything. I understand that it is needed for NETCONF (filters) and for YANG (augments, constraints) and so must be somewhere and must be relatively stable, but has it any other significance in the data model? As you may recall, I was involved with SMI first, where the root is somewhere up in the sky and life only becomes interesting some six levels down the hierarchy and that may colour my thinking. YANG does a poor job of defining the root for YANG data nodes. It is sometimes called a datastore (in the abstract). Technically, YANG borrows the definition from XPath. YANG just defines top-level data nodes and the parent of these nodes is the document root There is no protocol or encoding neutral definition, only an XML-specific definition. tp Thanks for that. It seems to me that much of the extensive discussion on Y34 (all of which I have read) is as much political as technical, that is SMI is hierarchical, top down, perhaps befitting its origins in ISO, whereas YANG is bottom up. IETF-like. YANG could have had a single tree, but doesn't. So when I read https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt I see a plea for a more hierarchical organisation, and when I read draft-bjorklund-netmod
Re: [netmod] Y34 - root node
From: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com Date: Monday, August 10, 2015 at 4:15 PM To: Acee Lindem a...@cisco.commailto:a...@cisco.com Cc: Einar Nilsen-Nygaard (einarnn) eina...@cisco.commailto:eina...@cisco.com, Jonathan Hansford jonat...@hansfords.netmailto:jonat...@hansfords.net, NETMOD Working Group netmod@ietf.orgmailto:netmod@ietf.org Subject: Re: [netmod] Y34 - root node On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) a...@cisco.commailto: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 netmod-boun...@ietf.orgmailto:netmod-boun...@ietf.org on behalf of Einar Nilsen-Nygaard (einarnn) eina...@cisco.commailto:eina...@cisco.com Date: Monday, August 10, 2015 at 5:29 AM To: Jonathan Hansford jonat...@hansfords.netmailto:jonat...@hansfords.net Cc: NETMOD Working Group netmod@ietf.orgmailto: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 jonat...@hansfords.netmailto: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) eina...@cisco.commailto:eina...@cisco.com To: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com Cc: NETMOD Working Group netmod@ietf.orgmailto: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
Re: [netmod] Y34 - root node
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 netmod-boun...@ietf.orgmailto:netmod-boun...@ietf.org on behalf of Einar Nilsen-Nygaard (einarnn) eina...@cisco.commailto:eina...@cisco.com Date: Monday, August 10, 2015 at 5:29 AM To: Jonathan Hansford jonat...@hansfords.netmailto:jonat...@hansfords.net Cc: NETMOD Working Group netmod@ietf.orgmailto: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 jonat...@hansfords.netmailto: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) eina...@cisco.commailto:eina...@cisco.com To: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com Cc: NETMOD Working Group netmod@ietf.orgmailto: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 a...@yumaworks.commailto:a...@yumaworks.com wrote: On Tue, Aug 4, 2015 at 2:34 AM, t.petch ie...@btconnect.commailto:ie...@btconnect.com wrote: - Original Message - From: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com To: t.petch ie...@btconnect.commailto:ie...@btconnect.com Sent: Monday, August 03, 2015 5:17 PM - Original Message - From: Andy Bierman andy@yumaworkscommailto:a...@yumaworks.com To: t.petch ie...@btconnect.commailto:ie...@btconnect.com Sent: Monday, August 03, 2015 4:10 PM - Original Message - From: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com Sent: Saturday, August 01, 2015 7:05 PM On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com On 8/1/15, 2:51 AM, j.schoenwael...@jacobs-university.demailto: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. tp One aspect of YANG I have never grasped is what a root means, if anything. I understand that it is needed for NETCONF (filters) and for YANG (augments, constraints) and so must be somewhere and must be relatively stable, but has it any other significance in the data model? As you may recall, I was involved with SMI first, where the root is somewhere up in the sky and life only becomes interesting some six levels down the hierarchy and that may colour my thinking. YANG does a poor job of defining the root for YANG data nodes. It is sometimes called a datastore (in the abstract). Technically, YANG borrows the definition from XPath. YANG just defines top-level data nodes
Re: [netmod] Y34 - root node
On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) 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? 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 netmod-boun...@ietf.org on behalf of Einar Nilsen-Nygaard (einarnn) eina...@cisco.com Date: Monday, August 10, 2015 at 5:29 AM To: Jonathan Hansford jonat...@hansfords.net Cc: NETMOD Working Group 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 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) eina...@cisco.com To: Andy Bierman a...@yumaworks.com Cc: NETMOD Working Group 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 a...@yumaworks.com wrote: On Tue, Aug 4, 2015 at 2:34 AM, t.petch ie...@btconnect.com wrote: - Original Message - From: Andy Bierman a...@yumaworks.com To: t.petch ie...@btconnect.com Sent: Monday, August 03, 2015 5:17 PM - Original Message - From: Andy Bierman andy@yumaworkscom a...@yumaworks.com To: t.petch 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) 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
Re: [netmod] Y34 - root node
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? 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,
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 jonat...@hansfords.netmailto: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) eina...@cisco.commailto:eina...@cisco.com To: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com Cc: NETMOD Working Group netmod@ietf.orgmailto: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 a...@yumaworks.commailto:a...@yumaworks.com wrote: On Tue, Aug 4, 2015 at 2:34 AM, t.petch ie...@btconnect.commailto:ie...@btconnect.com wrote: - Original Message - From: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com To: t.petch ie...@btconnect.commailto:ie...@btconnect.com Sent: Monday, August 03, 2015 5:17 PM - Original Message - From: Andy Bierman andy@yumaworkscommailto:a...@yumaworks.com To: t.petch ie...@btconnect.commailto:ie...@btconnect.com Sent: Monday, August 03, 2015 4:10 PM - Original Message - From: Andy Bierman a...@yumaworks.commailto:a...@yumaworks.com Sent: Saturday, August 01, 2015 7:05 PM On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com On 8/1/15, 2:51 AM, j.schoenwael...@jacobs-university.demailto: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. tp One aspect of YANG I have never grasped is what a root means, if anything. I understand that it is needed for NETCONF (filters) and for YANG (augments, constraints) and so must be somewhere and must be relatively stable, but has it any other significance in the data model? As you may recall, I was involved with SMI first, where the root is somewhere up in the sky and life only becomes interesting some six levels down the hierarchy and that may colour my thinking. YANG does a poor job of defining the root for YANG data nodes. It is sometimes called a datastore (in the abstract). Technically, YANG borrows the definition from XPath. YANG just defines top-level data nodes and the parent of these nodes is the document root There is no protocol or encoding neutral definition, only an XML-specific definition. tp Thanks for that. It seems to me that much of the extensive discussion on Y34 (all of which I have read) is as much political as technical, that is SMI is hierarchical, top down, perhaps befitting its origins in ISO, whereas YANG is bottom up. IETF-like. YANG could have had a single tree, but doesn't. So when I read https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt I see a plea for a more hierarchical organisation, and when I read draft-bjorklund-netmod-openconfig-reply-00 I see a response that says we are not like that. If so, I doubt that there ever will be a technical solution. And I am mindful that when I configure routing in a (Cisco) router, I have to do some of it under the interface definitions and some of it under the definition of the routing protocol. Which is life, never wholy interface-centric and never wholy routing protocol-centric! Are you saying
Re: [netmod] Y34 - root node
On Mon, Aug 3, 2015 at 9:01 AM, t.petch ie...@btconnect.com wrote: - Original Message - From: Andy Bierman a...@yumaworks.com To: t.petch ie...@btconnect.com Cc: NETMOD Working Group netmod@ietf.org Sent: Monday, August 03, 2015 4:10 PM On Mon, Aug 3, 2015 at 7:48 AM, t.petch ie...@btconnect.com 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) a...@cisco.com 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. tp One aspect of YANG I have never grasped is what a root means, if anything. I understand that it is needed for NETCONF (filters) and for YANG (augments, constraints) and so must be somewhere and must be relatively stable, but has it any other significance in the data model? As you may recall, I was involved with SMI first, where the root is somewhere up in the sky and life only becomes interesting some six levels down the hierarchy and that may colour my thinking. YANG does a poor job of defining the root for YANG data nodes. It is sometimes called a datastore (in the abstract). Technically, YANG borrows the definition from XPath. YANG just defines top-level data nodes and the parent of these nodes is the document root. There is no protocol or encoding neutral definition, only an XML-specific definition. tp Thanks for that. It seems to me that much of the extensive discussion on Y34 (all of which I have read) is as much political as technical, that is SMI is hierarchical, top down, perhaps befitting its origins in ISO, whereas YANG is bottom up. IETF-like. YANG could have had a single tree, but doesn't. So when I read https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt I see a plea for a more hierarchical organisation, and when I read draft-bjorklund-netmod-openconfig-reply-00 I see a response that says we are not like that. If so, I doubt that there ever will be a technical solution. And I am mindful that when I configure routing in a (Cisco) router, I have to do some of it under the interface definitions and some of it under the definition of the routing protocol. Which is life, never wholy interface-centric and never wholy routing protocol-centric! Are you saying the job would be easier if the path was /device/interfaces/interface instead of just /interfaces/interface? Are you saying that /protocols/routing could not also be defined? Clearly edit-config and copy-config allow both subtrees to be accessed in the same operation, so I don't understand your concern. I have been trying to get the root node to be better defined in the protocols that use YANG (i.e., ncx:root, Y34-04). IMO this is a better approach than defining a YANG module with a special container that all other modules are expected to augment. YANG is designed such that each vendor or SDO is not dependent on other vendors or SDOs in order to define data nodes. 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
Re: [netmod] Y34
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 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y34
On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger lber...@labn.net 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 config 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 a...@yumaworks.com 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) 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
On 7/20/15, 11:00 PM, netmod on behalf of Juergen Schoenwaelder
netmod-boun...@ietf.org on behalf of
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 a...@yumaworks.com wrote:
On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka lho...@nic.cz
wrote:
On 20 Jul 2015, at 17:00, Andy Bierman a...@yumaworks.com
wrote:
On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka lho...@nic.cz
wrote:
On 20 Jul 2015, at 14:55, Andy Bierman a...@yumaworks.com
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
Re: [netmod] Y34
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) 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 On 7/20/15, 11:00 PM, netmod on behalf of Juergen Schoenwaelder netmod-boun...@ietf.org on behalf of 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 a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 17:00, Andy Bierman a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 14:55, Andy Bierman a...@yumaworks.com 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 lho...@nic.cz wrote: On 20 Jul 2015, at
Re: [netmod] Y34
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) 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 On 7/20/15, 11:00 PM, netmod on behalf of Juergen Schoenwaelder netmod-boun...@ietf.org on behalf of 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 a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 17:00, Andy Bierman a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 14:55, Andy Bierman a...@yumaworks.com 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
Re: [netmod] Y34
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 a...@yumaworks.com 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) 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 On 7/20/15, 11:00 PM, netmod on behalf of Juergen Schoenwaelder netmod-boun...@ietf.org on behalf of 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 a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 17:00, Andy Bierman a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 14:55, Andy Bierman a...@yumaworks.com 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
Re: [netmod] Y34
On 20 Jul 2015, at 23:00, 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. 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 a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 17:00, Andy Bierman a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 14:55, Andy Bierman a...@yumaworks.com 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 lho...@nic.cz wrote: On 20 Jul 2015, at 14:45, Ladislav Lhotka
Re: [netmod] Y34
On 21 Jul 2015, at 09:44, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Jul 21, 2015 at 09:16:46AM +0200, Ladislav Lhotka wrote: On 20 Jul 2015, at 23:00, 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. 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 http://www.jacobs-university.de/ -- 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
On 20 Jul 2015, at 14:45, Ladislav Lhotka lho...@nic.cz 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
Re: [netmod] Y34
On 20 Jul 2015, at 17:00, Andy Bierman a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 14:55, Andy Bierman a...@yumaworks.com 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 lho...@nic.cz wrote: On 20 Jul 2015, at 14:45, Ladislav Lhotka lho...@nic.cz 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 -- Ladislav Lhotka,
Re: [netmod] Y34
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 a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 17:00, Andy Bierman a...@yumaworks.com wrote: On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka lho...@nic.cz wrote: On 20 Jul 2015, at 14:55, Andy Bierman a...@yumaworks.com 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 lho...@nic.cz wrote: On 20 Jul 2015, at 14:45, Ladislav Lhotka lho...@nic.cz 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]
