Re: [netmod] Y34

[Andy Bierman <[e-mail]>]

On Fri, Jul 31, 2015 at 9:46 AM, Lou Berger <[e-mail]> 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.
>
> Perhaps you'd be willing to have a brain storming session off-line?  (Of
> course, any proposed changes/approaches would be brought to the WG for
> normal WG processing.)
>
>
OK -- send an email invite to the meeting.



> Lou
>
>

Andy


> > For example, a resource directory of symlinks
> > (YANG leaf, type instance-identifier) would allow
> > standard or vendor modules to be supported.
> > The exact location of the data nodes can change over time,
> > and be different on each server.
> >
> >
> > Andy
> >
> > On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     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]
> >     <mailto:[e-mail]>> wrote:
> >
> >>
> >>
> >>     On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <[e-mail]
> >>     <mailto:[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]
> >>         <mailto:[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] <mailto:[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] <mailto:[e-mail]>
> >>>             on behalf of
> >>>             [e-mail]
> >>>             <mailto:[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] <mailto:[e-mail]>> wrote:
> >>>             >> >
> >>>             >> >
> >>>             >> >
> >>>             >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka
> >>>             <[e-mail] <mailto:[e-mail]>>
> >>>             >>wrote:
> >>>             >> >
> >>>             >> > > On 20 Jul 2015, at 17:00, Andy Bierman
> >>>             <[e-mail] <mailto:[e-mail]>> wrote:
> >>>             >> > >
> >>>             >> > >
> >>>             >> > >
> >>>             >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka
> >>>             <[e-mail] <mailto:[e-mail]>>
> >>>             >>wrote:
> >>>             >> > >
> >>>             >> > > > On 20 Jul 2015, at 14:55, Andy Bierman
> >>>             <[e-mail] <mailto:[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] <mailto:[e-mail]>>
> >>>             >>wrote:
> >>>             >> > > >
> >>>             >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka
> >>>             <[e-mail] <mailto:[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] <mailto:[e-mail]>
> >>>             >> > > > > https://www.ietf.org/mailman/listinfo/netmod
> >>>             >> > > >
> >>>             >> > > > --
> >>>             >> > > > Ladislav Lhotka, CZ.NIC Labs
> >>>             >> > > > PGP Key ID: E74E8C0C
> >>>             >> > > >
> >>>             >> > > >
> >>>             >> > > >
> >>>             >> > > >
> >>>             >> > > > _______________________________________________
> >>>             >> > > > netmod mailing list
> >>>             >> > > > [e-mail] <mailto:[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] <mailto:[e-mail]>
> >>>             >> > https://www.ietf.org/mailman/listinfo/netmod
> >>>             >>
> >>>             >> --
> >>>             >> Ladislav Lhotka, CZ.NIC Labs
> >>>             >> PGP Key ID: E74E8C0C
> >>>             >>
> >>>             >>
> >>>             >>
> >>>             >>
> >>>             >> _______________________________________________
> >>>             >> netmod mailing list
> >>>             >> [e-mail] <mailto:[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] <mailto:[e-mail]>
> >>>             >https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>>             _______________________________________________
> >>>             netmod mailing list
> >>>             [e-mail] <mailto:[e-mail]>
> >>>             https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>>
> >>>         _______________________________________________
> >>>         netmod mailing list
> >>>         [e-mail] <mailto:netmod%40ietf.org>
> >>>         https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>
> >
>
>