> 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, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
