I do not think this is Y34. Relocating YANG models is not covered by any of the YANG 1.1 issues as far as I can tell and issue submission closed about a year ago. I suggest someone interested in such a feature writes an independent I-D. And as usual, the devil is in the details.
/js On Sun, Jul 26, 2015 at 05:49:17PM +0000, Acee Lindem (acee) wrote: > I think being able to place a given model anywhere in the device tree > would be useful and this would allow a model to be rooted in different > locations on different devices. Similarly, we’d need the ability to prefix > XPATH references to data nodes in the model with the root. > Thanks, > Acee > > On 7/20/15, 11:00 PM, "netmod on behalf of Juergen Schoenwaelder" > <[email protected] on behalf of > [email protected]> 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 <[email protected]> wrote: > >> > > >> > > >> > > >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <[email protected]> > >>wrote: > >> > > >> > > On 20 Jul 2015, at 17:00, Andy Bierman <[email protected]> wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <[email protected]> > >>wrote: > >> > > > >> > > > On 20 Jul 2015, at 14:55, Andy Bierman <[email protected]> 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 <[email protected]> > >>wrote: > >> > > > > >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <[email protected]> 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 > >> > > > > [email protected] > >> > > > > https://www.ietf.org/mailman/listinfo/netmod > >> > > > > >> > > > -- > >> > > > Ladislav Lhotka, CZ.NIC Labs > >> > > > PGP Key ID: E74E8C0C > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > netmod mailing list > >> > > > [email protected] > >> > > > https://www.ietf.org/mailman/listinfo/netmod > >> > > > > >> > > > >> > > -- > >> > > Ladislav Lhotka, CZ.NIC Labs > >> > > PGP Key ID: E74E8C0C > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > -- > >> > Ladislav Lhotka, CZ.NIC Labs > >> > PGP Key ID: E74E8C0C > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > netmod mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/netmod > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > >_______________________________________________ > >netmod mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/netmod > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
