Re: [netmod] Y34

[Lou Berger <[e-mail]>]

Andy,

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

Lou


On July 27, 2015 2:19:09 AM Andy Bierman <[e-mail]> wrote:

> On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <[e-mail]> 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 <[e-mail]> 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) <[e-mail]>
> >> 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"
> >>> <[e-mail] on behalf of
> >>> [e-mail]> 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 <[e-mail]> wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka <[e-mail]>
> >>> >>wrote:
> >>> >> >
> >>> >> > > On 20 Jul 2015, at 17:00, Andy Bierman <[e-mail]>
> >>> wrote:
> >>> >> > >
> >>> >> > >
> >>> >> > >
> >>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <[e-mail]>
> >>> >>wrote:
> >>> >> > >
> >>> >> > > > On 20 Jul 2015, at 14:55, Andy Bierman <[e-mail]>
> >>> 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 <[e-mail]
> >>> >
> >>> >>wrote:
> >>> >> > > >
> >>> >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka <[e-mail]>
> >>> 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
> >>> >> > > > > [e-mail]
> >>> >> > > > > https://www.ietf.org/mailman/listinfo/netmod
> >>> >> > > >
> >>> >> > > > --
> >>> >> > > > Ladislav Lhotka, CZ.NIC Labs
> >>> >> > > > PGP Key ID: E74E8C0C
> >>> >> > > >
> >>> >> > > >
> >>> >> > > >
> >>> >> > > >
> >>> >> > > > _______________________________________________
> >>> >> > > > netmod mailing list
> >>> >> > > > [e-mail]
> >>> >> > > > 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
> >>> >> > [e-mail]
> >>> >> > https://www.ietf.org/mailman/listinfo/netmod
> >>> >>
> >>> >> --
> >>> >> Ladislav Lhotka, CZ.NIC Labs
> >>> >> PGP Key ID: E74E8C0C
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> netmod mailing list
> >>> >> [e-mail]
> >>> >> https://www.ietf.org/mailman/listinfo/netmod
> >>> >
> >>> >--
> >>> >Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> >Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>> >Fax:   [phone]         <http://www.jacobs-university.de/>
> >>> >
> >>> >_______________________________________________
> >>> >netmod mailing list
> >>> >[e-mail]
> >>> >https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >>