Re: [netmod] Y34

[Lou Berger <[e-mail]>]

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.)

Lou

> 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
>>>
>>
>