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 wrote: > > > > > > > > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > > > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > Can you explain why we need 2 broken anyxmls? > > > > (The original and a synonym?) The whole point of > > > > anydata is that it does not have XML cruft in it. > > > > > > Yes, I understand this was your main priority. For implementors using > > > off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > > > > > > > > yes it is an issue. > > > We need something to model a container full of arbitrary YANG data nodes. > > > This is something that can be applied to the contents of a datastore. > > > > anyxml can do that, too. > > > > > > the WG already decided it can't. > > The extra XML PIs, etc. are not accepted by all servers, remember? > > There is no use for the extra stuff in the datastore. > > I don't see why we need 2 anyxml constructs that are not > > supported by the industry. One is already too many. > > I agree, but this is what we are going to have. My proposal was to have just > one with two different names. > > > > > > > > > > > > > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with > > > no (YANG) schema available. My only complaint to “anyxml” has always been > > > that it is a misnomer for encodings other than XML. > > > > > > The message encoding on the wire is not the same issue > > > as the contents of a datastore. Our server stores its own > > > internal data structures. XML, JSON, CBOR are just message > > > encoding formats between client and server. The datastore > > > is not encoded in any of these formats. > > > > The payload of anyxml needn’t directly map to a data subtree in the usual > > sense. > > > > that's precisely the difference between anyxml and anydata. > > The anydata node MUST map directly into data subtrees. > > If the server doesn’t know the YANG data model at run time (which is > possible) then it cannot do it - for instance, it cannot properly map module > names to namespace URI or handle lists. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also don't get the value of a single top-level node called 'device' > > > > that every YANG model on the planet is supposed to augment. > > > > Can you explain why a protocol operation to retrieve the > > > > document root (/) is not sufficient for the top-level node? > > > > > > I don’t intend to defend their model, the more serious problem IMO is > > > that a model for a single device/function may be needed in another device > > > that hosts many virtualised devices/functions of the former type. We > > > don’t have a good solution for this rather typical situation. > > > > > > But a single container called "whatever" provides no such aggregation. > > > You would need a list for that. And the NMS might have multiple > > > layers of hierarchy to represent various aggregations. The NP > > > container called "device" is not helpful for aggregation. > > > > The parent node can be a list as well. The “root” node would be like a > > mount point in a Unix filesystem. > > > > > > Are you saying all data on a device needs to be in a top-level list called > > 'device' > > because an NMS might exist that wants to have the datastores from lots of > > devices? > > As Martin pointed out several times, the NMS can make its own container or > > lists. It does not need the device to mirror its own structure. > > As I said, I don’t care that much about the “device” container. What would be > really useful is to have the possibility to do e.g. this: > > virtual-node* [name] > name > if:interfaces > ... > > to support the use case where all virtual nodes are managed by the same > NETCONF/RESTCONF server. > > Lada > > > > > > > > > Lada > > > > Andy > > > > > > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > > > > > Hi, > > > > > > > > > > after listening to the presentation of > > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > > > > whether the solution chosen for Y34 is really useful. > > > > > > > > > > The draft st
Re: [netmod] draft-ietf-netmod-syslog-model-04.txt Implementations
Clyde, Excellent, thanks! > On Jul 20, 2015, at 7:57 PM, Clyde Wildes (cwildes) wrote: > > Carl, > > Thanks for your question in the Netmod meeting during the review of the > ietf-syslog model. > > Regarding the model implementation: the model has been implemented in ODL and > internally in Cisco's NXOS. > > Thanks, > > Clyde > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] draft-ietf-netmod-syslog-model-04.txt Implementations
Carl, Thanks for your question in the Netmod meeting during the review of the ietf-syslog model. Regarding the model implementation: the model has been implemented in ODL and internally in Cisco's NXOS. Thanks, Clyde ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y34
> On 20 Jul 2015, at 19:29, Andy Bierman wrote: > > > > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > > > > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > > > Hi, > > > > > > Can you explain why we need 2 broken anyxmls? > > > (The original and a synonym?) The whole point of > > > anydata is that it does not have XML cruft in it. > > > > Yes, I understand this was your main priority. For implementors using > > off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > > > > > yes it is an issue. > > We need something to model a container full of arbitrary YANG data nodes. > > This is something that can be applied to the contents of a datastore. > > anyxml can do that, too. > > > the WG already decided it can't. > The extra XML PIs, etc. are not accepted by all servers, remember? > There is no use for the extra stuff in the datastore. > I don't see why we need 2 anyxml constructs that are not > supported by the industry. One is already too many. I agree, but this is what we are going to have. My proposal was to have just one with two different names. > > > > > > > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no > > (YANG) schema available. My only complaint to “anyxml” has always been that > > it is a misnomer for encodings other than XML. > > > > The message encoding on the wire is not the same issue > > as the contents of a datastore. Our server stores its own > > internal data structures. XML, JSON, CBOR are just message > > encoding formats between client and server. The datastore > > is not encoded in any of these formats. > > The payload of anyxml needn’t directly map to a data subtree in the usual > sense. > > that's precisely the difference between anyxml and anydata. > The anydata node MUST map directly into data subtrees. If the server doesn’t know the YANG data model at run time (which is possible) then it cannot do it - for instance, it cannot properly map module names to namespace URI or handle lists. > > > > > > > > > > > > > > > > > > > I also don't get the value of a single top-level node called 'device' > > > that every YANG model on the planet is supposed to augment. > > > Can you explain why a protocol operation to retrieve the > > > document root (/) is not sufficient for the top-level node? > > > > I don’t intend to defend their model, the more serious problem IMO is that > > a model for a single device/function may be needed in another device that > > hosts many virtualised devices/functions of the former type. We don’t have > > a good solution for this rather typical situation. > > > > But a single container called "whatever" provides no such aggregation. > > You would need a list for that. And the NMS might have multiple > > layers of hierarchy to represent various aggregations. The NP > > container called "device" is not helpful for aggregation. > > The parent node can be a list as well. The “root” node would be like a mount > point in a Unix filesystem. > > > Are you saying all data on a device needs to be in a top-level list called > 'device' > because an NMS might exist that wants to have the datastores from lots of > devices? > As Martin pointed out several times, the NMS can make its own container or > lists. It does not need the device to mirror its own structure. As I said, I don’t care that much about the “device” container. What would be really useful is to have the possibility to do e.g. this: virtual-node* [name] name if:interfaces ... to support the use case where all virtual nodes are managed by the same NETCONF/RESTCONF server. Lada > > > > Lada > > Andy > > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > Andy > > > > > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > > > Hi, > > > > > > > > after listening to the presentation of > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > > > whether the solution chosen for Y34 is really useful. > > > > > > > > The draft states they want to reuse ietf-interfaces but their tree in > > > > fact is > > > > > > > > +--rw device > > > > +--rw info > > > > | +--rw device-type? enumeration > > > > +--rw hardware > > > > +--rw interfaces > > > > | +--rw interface* [name] > > > > | ... > > > > +--rw qos > > > > > > > > So the "interfaces" container is no more a top-level node. There are > > > > three possible options: > > > > > > > > 1. Change the ietf-interfaces module. > > > > 2. Replicate its contents in another module. > > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > > given data node. > > > > > > > > IMO #1 & #2 are r
Re: [netmod] Y34
On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > > > > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > > > Hi, > > > > > > Can you explain why we need 2 broken anyxmls? > > > (The original and a synonym?) The whole point of > > > anydata is that it does not have XML cruft in it. > > > > Yes, I understand this was your main priority. For implementors using > off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > > > > > yes it is an issue. > > We need something to model a container full of arbitrary YANG data nodes. > > This is something that can be applied to the contents of a datastore. > > anyxml can do that, too. > the WG already decided it can't. The extra XML PIs, etc. are not accepted by all servers, remember? There is no use for the extra stuff in the datastore. I don't see why we need 2 anyxml constructs that are not supported by the industry. One is already too many. > > > > > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with > no (YANG) schema available. My only complaint to “anyxml” has always been > that it is a misnomer for encodings other than XML. > > > > The message encoding on the wire is not the same issue > > as the contents of a datastore. Our server stores its own > > internal data structures. XML, JSON, CBOR are just message > > encoding formats between client and server. The datastore > > is not encoded in any of these formats. > > The payload of anyxml needn’t directly map to a data subtree in the usual > sense. > that's precisely the difference between anyxml and anydata. The anydata node MUST map directly into data subtrees. > > > > > > > > > > > > > > > > > I also don't get the value of a single top-level node called 'device' > > > that every YANG model on the planet is supposed to augment. > > > Can you explain why a protocol operation to retrieve the > > > document root (/) is not sufficient for the top-level node? > > > > I don’t intend to defend their model, the more serious problem IMO is > that a model for a single device/function may be needed in another device > that hosts many virtualised devices/functions of the former type. We don’t > have a good solution for this rather typical situation. > > > > But a single container called "whatever" provides no such aggregation. > > You would need a list for that. And the NMS might have multiple > > layers of hierarchy to represent various aggregations. The NP > > container called "device" is not helpful for aggregation. > > The parent node can be a list as well. The “root” node would be like a > mount point in a Unix filesystem. > > Are you saying all data on a device needs to be in a top-level list called 'device' because an NMS might exist that wants to have the datastores from lots of devices? As Martin pointed out several times, the NMS can make its own container or lists. It does not need the device to mirror its own structure. Lada > Andy > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > Andy > > > > > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka > wrote: > > > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > > > Hi, > > > > > > > > after listening to the presentation of > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am > wondering > > > > whether the solution chosen for Y34 is really useful. > > > > > > > > The draft states they want to reuse ietf-interfaces but their tree in > > > > fact is > > > > > > > > +--rw device > > > > +--rw info > > > > | +--rw device-type? enumeration > > > > +--rw hardware > > > > +--rw interfaces > > > > | +--rw interface* [name] > > > > | ... > > > > +--rw qos > > > > > > > > So the "interfaces" container is no more a top-level node. There are > > > > three possible options: > > > > > > > > 1. Change the ietf-interfaces module. > > > > 2. Replicate its contents in another module. > > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > > given data node. > > > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but > it > > > > seems it is not so because it doesn't specify a concrete data model > > > > that's allowed at a given location. > > > > > > > > On the other hand, the only real contribution of "anydata" over > "anyxml" > > > > is that is doesn't permit mixed content in XML, which is IMO not > much. > > > > > > > > I know Y34 was already closed but I think it is more important to do > > > > things right before YANG 1.1 becomes an RFC. > > > > > > > > What I want to propose is this: > > > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" > (but > > > > keep it for backward compatibility). > > > > > > s/Rename/Introduce/ > > > > > > > > > > > - Introduce a ne
Re: [netmod] Y34
> On 20 Jul 2015, at 17:00, Andy Bierman wrote: > > > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > Hi, > > > > Can you explain why we need 2 broken anyxmls? > > (The original and a synonym?) The whole point of > > anydata is that it does not have XML cruft in it. > > Yes, I understand this was your main priority. For implementors using > off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > > yes it is an issue. > We need something to model a container full of arbitrary YANG data nodes. > This is something that can be applied to the contents of a datastore. anyxml can do that, too. > > > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no > (YANG) schema available. My only complaint to “anyxml” has always been that > it is a misnomer for encodings other than XML. > > The message encoding on the wire is not the same issue > as the contents of a datastore. Our server stores its own > internal data structures. XML, JSON, CBOR are just message > encoding formats between client and server. The datastore > is not encoded in any of these formats. The payload of anyxml needn’t directly map to a data subtree in the usual sense. > > > > > > > > > I also don't get the value of a single top-level node called 'device' > > that every YANG model on the planet is supposed to augment. > > Can you explain why a protocol operation to retrieve the > > document root (/) is not sufficient for the top-level node? > > I don’t intend to defend their model, the more serious problem IMO is that a > model for a single device/function may be needed in another device that hosts > many virtualised devices/functions of the former type. We don’t have a good > solution for this rather typical situation. > > But a single container called "whatever" provides no such aggregation. > You would need a list for that. And the NMS might have multiple > layers of hierarchy to represent various aggregations. The NP > container called "device" is not helpful for aggregation. The parent node can be a list as well. The “root” node would be like a mount point in a Unix filesystem. Lada > > > > Lada > > > Andy > > > > > > Andy > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > Hi, > > > > > > after listening to the presentation of > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > > whether the solution chosen for Y34 is really useful. > > > > > > The draft states they want to reuse ietf-interfaces but their tree in > > > fact is > > > > > > +--rw device > > > +--rw info > > > | +--rw device-type? enumeration > > > +--rw hardware > > > +--rw interfaces > > > | +--rw interface* [name] > > > | ... > > > +--rw qos > > > > > > So the "interfaces" container is no more a top-level node. There are > > > three possible options: > > > > > > 1. Change the ietf-interfaces module. > > > 2. Replicate its contents in another module. > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > given data node. > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > > > seems it is not so because it doesn't specify a concrete data model > > > that's allowed at a given location. > > > > > > On the other hand, the only real contribution of "anydata" over "anyxml" > > > is that is doesn't permit mixed content in XML, which is IMO not much. > > > > > > I know Y34 was already closed but I think it is more important to do > > > things right before YANG 1.1 becomes an RFC. > > > > > > What I want to propose is this: > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but > > > keep it for backward compatibility). > > > > s/Rename/Introduce/ > > > > > > > > - Introduce a new statement and data node type, e.g. "root", that will > > > extend the schema tree starting from that data node with a precisely > > > specified data model. The specification can be same or similar as > > > in yang-library. > > > > > > I believe there are other use cases in the existing modules. For > > > example, the ietf-routing module could simply define the data model for > > > a single routing instance (i.e. without "routing-instance" list at the > > > top), and it can be then used without changes on simple devices, and > > > more complex router implementations can graft it as a subtree under > > > "routing-instance", "networking-instance" or whatever. > > > > > > Lada > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > ___ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E7
Re: [netmod] Y34
On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > > > Hi, > > > > Can you explain why we need 2 broken anyxmls? > > (The original and a synonym?) The whole point of > > anydata is that it does not have XML cruft in it. > > Yes, I understand this was your main priority. For implementors using > off-the-shelf XML parsers and tools the XML cruft is not an issue at all. > > yes it is an issue. We need something to model a container full of arbitrary YANG data nodes. This is something that can be applied to the contents of a datastore. > Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with > no (YANG) schema available. My only complaint to “anyxml” has always been > that it is a misnomer for encodings other than XML. > The message encoding on the wire is not the same issue as the contents of a datastore. Our server stores its own internal data structures. XML, JSON, CBOR are just message encoding formats between client and server. The datastore is not encoded in any of these formats. > > > > > I also don't get the value of a single top-level node called 'device' > > that every YANG model on the planet is supposed to augment. > > Can you explain why a protocol operation to retrieve the > > document root (/) is not sufficient for the top-level node? > > I don’t intend to defend their model, the more serious problem IMO is that > a model for a single device/function may be needed in another device that > hosts many virtualised devices/functions of the former type. We don’t have > a good solution for this rather typical situation. > But a single container called "whatever" provides no such aggregation. You would need a list for that. And the NMS might have multiple layers of hierarchy to represent various aggregations. The NP container called "device" is not helpful for aggregation. > Lada > Andy > > > > > Andy > > > > > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > > > Hi, > > > > > > after listening to the presentation of > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > > whether the solution chosen for Y34 is really useful. > > > > > > The draft states they want to reuse ietf-interfaces but their tree in > > > fact is > > > > > > +--rw device > > > +--rw info > > > | +--rw device-type? enumeration > > > +--rw hardware > > > +--rw interfaces > > > | +--rw interface* [name] > > > | ... > > > +--rw qos > > > > > > So the "interfaces" container is no more a top-level node. There are > > > three possible options: > > > > > > 1. Change the ietf-interfaces module. > > > 2. Replicate its contents in another module. > > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > > given data node. > > > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > > > seems it is not so because it doesn't specify a concrete data model > > > that's allowed at a given location. > > > > > > On the other hand, the only real contribution of "anydata" over > "anyxml" > > > is that is doesn't permit mixed content in XML, which is IMO not much. > > > > > > I know Y34 was already closed but I think it is more important to do > > > things right before YANG 1.1 becomes an RFC. > > > > > > What I want to propose is this: > > > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" > (but > > > keep it for backward compatibility). > > > > s/Rename/Introduce/ > > > > > > > > - Introduce a new statement and data node type, e.g. "root", that will > > > extend the schema tree starting from that data node with a precisely > > > specified data model. The specification can be same or similar as > > > in yang-library. > > > > > > I believe there are other use cases in the existing modules. For > > > example, the ietf-routing module could simply define the data model for > > > a single routing instance (i.e. without "routing-instance" list at the > > > top), and it can be then used without changes on simple devices, and > > > more complex router implementations can graft it as a subtree under > > > "routing-instance", "networking-instance" or whatever. > > > > > > Lada > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > ___ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > ___ netmod mailing list netmod@ietf.org https://www.ie
Re: [netmod] Y34
> On 20 Jul 2015, at 14:55, Andy Bierman wrote: > > Hi, > > Can you explain why we need 2 broken anyxmls? > (The original and a synonym?) The whole point of > anydata is that it does not have XML cruft in it. Yes, I understand this was your main priority. For implementors using off-the-shelf XML parsers and tools the XML cruft is not an issue at all. Anyway, I believe there are use cases for arbitrary XML/JSON/CBOR/… with no (YANG) schema available. My only complaint to “anyxml” has always been that it is a misnomer for encodings other than XML. > > I also don't get the value of a single top-level node called 'device' > that every YANG model on the planet is supposed to augment. > Can you explain why a protocol operation to retrieve the > document root (/) is not sufficient for the top-level node? I don’t intend to defend their model, the more serious problem IMO is that a model for a single device/function may be needed in another device that hosts many virtualised devices/functions of the former type. We don’t have a good solution for this rather typical situation. Lada > > Andy > > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > Hi, > > > > after listening to the presentation of > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > whether the solution chosen for Y34 is really useful. > > > > The draft states they want to reuse ietf-interfaces but their tree in > > fact is > > > > +--rw device > > +--rw info > > | +--rw device-type? enumeration > > +--rw hardware > > +--rw interfaces > > | +--rw interface* [name] > > | ... > > +--rw qos > > > > So the "interfaces" container is no more a top-level node. There are > > three possible options: > > > > 1. Change the ietf-interfaces module. > > 2. Replicate its contents in another module. > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > given data node. > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > > seems it is not so because it doesn't specify a concrete data model > > that's allowed at a given location. > > > > On the other hand, the only real contribution of "anydata" over "anyxml" > > is that is doesn't permit mixed content in XML, which is IMO not much. > > > > I know Y34 was already closed but I think it is more important to do > > things right before YANG 1.1 becomes an RFC. > > > > What I want to propose is this: > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but > > keep it for backward compatibility). > > s/Rename/Introduce/ > > > > > - Introduce a new statement and data node type, e.g. "root", that will > > extend the schema tree starting from that data node with a precisely > > specified data model. The specification can be same or similar as > > in yang-library. > > > > I believe there are other use cases in the existing modules. For > > example, the ietf-routing module could simply define the data model for > > a single routing instance (i.e. without "routing-instance" list at the > > top), and it can be then used without changes on simple devices, and > > more complex router implementations can graft it as a subtree under > > "routing-instance", "networking-instance" or whatever. > > > > Lada > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y34
Hi, Can you explain why we need 2 broken anyxmls? (The original and a synonym?) The whole point of anydata is that it does not have XML cruft in it. I also don't get the value of a single top-level node called 'device' that every YANG model on the planet is supposed to augment. Can you explain why a protocol operation to retrieve the document root (/) is not sufficient for the top-level node? Andy On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka wrote: > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > > > Hi, > > > > after listening to the presentation of > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > > whether the solution chosen for Y34 is really useful. > > > > The draft states they want to reuse ietf-interfaces but their tree in > > fact is > > > > +--rw device > > +--rw info > > | +--rw device-type? enumeration > > +--rw hardware > > +--rw interfaces > > | +--rw interface* [name] > > | ... > > +--rw qos > > > > So the "interfaces" container is no more a top-level node. There are > > three possible options: > > > > 1. Change the ietf-interfaces module. > > 2. Replicate its contents in another module. > > 3. Extend YANG so that a *specific* schema tree can be grafted at a > > given data node. > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > > seems it is not so because it doesn't specify a concrete data model > > that's allowed at a given location. > > > > On the other hand, the only real contribution of "anydata" over "anyxml" > > is that is doesn't permit mixed content in XML, which is IMO not much. > > > > I know Y34 was already closed but I think it is more important to do > > things right before YANG 1.1 becomes an RFC. > > > > What I want to propose is this: > > > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but > > keep it for backward compatibility). > > s/Rename/Introduce/ > > > > > - Introduce a new statement and data node type, e.g. "root", that will > > extend the schema tree starting from that data node with a precisely > > specified data model. The specification can be same or similar as > > in yang-library. > > > > I believe there are other use cases in the existing modules. For > > example, the ietf-routing module could simply define the data model for > > a single routing instance (i.e. without "routing-instance" list at the > > top), and it can be then used without changes on simple devices, and > > more complex router implementations can graft it as a subtree under > > "routing-instance", "networking-instance" or whatever. > > > > Lada > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Y34
> On 20 Jul 2015, at 14:45, Ladislav Lhotka wrote: > > Hi, > > after listening to the presentation of > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering > whether the solution chosen for Y34 is really useful. > > The draft states they want to reuse ietf-interfaces but their tree in > fact is > > +--rw device > +--rw info > | +--rw device-type? enumeration > +--rw hardware > +--rw interfaces > | +--rw interface* [name] > | ... > +--rw qos > > So the "interfaces" container is no more a top-level node. There are > three possible options: > > 1. Change the ietf-interfaces module. > 2. Replicate its contents in another module. > 3. Extend YANG so that a *specific* schema tree can be grafted at a > given data node. > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it > seems it is not so because it doesn't specify a concrete data model > that's allowed at a given location. > > On the other hand, the only real contribution of "anydata" over "anyxml" > is that is doesn't permit mixed content in XML, which is IMO not much. > > I know Y34 was already closed but I think it is more important to do > things right before YANG 1.1 becomes an RFC. > > What I want to propose is this: > > - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but > keep it for backward compatibility). s/Rename/Introduce/ > > - Introduce a new statement and data node type, e.g. "root", that will > extend the schema tree starting from that data node with a precisely > specified data model. The specification can be same or similar as > in yang-library. > > I believe there are other use cases in the existing modules. For > example, the ietf-routing module could simply define the data model for > a single routing instance (i.e. without "routing-instance" list at the > top), and it can be then used without changes on simple devices, and > more complex router implementations can graft it as a subtree under > "routing-instance", "networking-instance" or whatever. > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Y34
Hi, after listening to the presentation of draft-rtgyangdt-rtgwg-device-model-00 at RTGWG session, I am wondering whether the solution chosen for Y34 is really useful. The draft states they want to reuse ietf-interfaces but their tree in fact is +--rw device +--rw info | +--rw device-type? enumeration +--rw hardware +--rw interfaces | +--rw interface* [name] | ... +--rw qos So the "interfaces" container is no more a top-level node. There are three possible options: 1. Change the ietf-interfaces module. 2. Replicate its contents in another module. 3. Extend YANG so that a *specific* schema tree can be grafted at a given data node. IMO #1 & #2 are really bad. I thought Y34-04 was essentially #3 but it seems it is not so because it doesn't specify a concrete data model that's allowed at a given location. On the other hand, the only real contribution of "anydata" over "anyxml" is that is doesn't permit mixed content in XML, which is IMO not much. I know Y34 was already closed but I think it is more important to do things right before YANG 1.1 becomes an RFC. What I want to propose is this: - Rename "anydata" as a synonym to "anyxml", and deprecate "anyxml" (but keep it for backward compatibility). - Introduce a new statement and data node type, e.g. "root", that will extend the schema tree starting from that data node with a precisely specified data model. The specification can be same or similar as in yang-library. I believe there are other use cases in the existing modules. For example, the ietf-routing module could simply define the data model for a single routing instance (i.e. without "routing-instance" list at the top), and it can be then used without changes on simple devices, and more complex router implementations can graft it as a subtree under "routing-instance", "networking-instance" or whatever. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
