Subject: [netmod] Y34

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jul 2015 14:45:09 +0200

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

- 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jul 2015 14:48:04 +0200

> On 20 Jul 2015, at 14:45, Ladislav Lhotka <[email-masked]> wrote:
> 
> Hi,
> 

s/Rename/Introduce/

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jul 2015 05:55:06 -0700

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.

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?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jul 2015 15:08:18 +0200

> On 20 Jul 2015, at 14:55, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

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.

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.

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

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jul 2015 08:00:32 -0700

On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <[email-masked]> wrote:

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

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

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

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jul 2015 19:15:56 +0200

> On 20 Jul 2015, at 17:00, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

anyxml can do that, too.

> is not encoded in any of these formats.

The payload of anyxml needn’t directly map to a data subtree in the usual sense.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Jul 2015 10:29:05 -0700

> > This is something that can be applied to the contents of a datastore.

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.

> The payload of anyxml needn’t directly map to a data subtree in the usual

that's precisely the difference between anyxml and anydata.
The anydata node MUST map directly into data subtrees.

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

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jul 2015 19:42:49 +0200

> On 20 Jul 2015, at 19:29, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

I agree, but this is what we are going to have. My proposal was to have just one with two different names.

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jul 2015 23:00:42 +0200

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Jul 2015 09:16:46 +0200

> On 20 Jul 2015, at 23:00, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Lada,
> 

Of course, I was expecting this reaction. I think I did present *some* arguments, and I am leaving it to others to judge whether they are relevant or not. Even if it was a minor mistake, it is IMO still worth fixing.

> issues for YANG 1.1 either at this point in time.)

It’s not about symlinks in the data tree but rather about a method for combining schemas that is complementary to “augment” - pull versus push.

There is sufficient evidence that it was one of the use cases for “anydata”, e.g. in configlets. The gap in “anydata” definition for similar use cases is that it cannot specify a schema for its contents.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jul 2015 09:44:28 +0200

> There is sufficient evidence that it was one of the use cases for “anydata”, e.g. in configlets. The gap in “anydata” definition for similar use cases is that it cannot specify a schema for its con…

Lada, you can't simply 'mount' a data model into a different place.
Think about paths in must or when expressions, or think about paths
contraints in leafrefs etc. And Y34 was not trying to solve this
problem, so this discussion is IMHO under a misleading subject line.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Jul 2015 11:21:19 +0200

> On 21 Jul 2015, at 09:44, Juergen Schoenwaelder <[email-masked]> wrote:
> 

This is a fair point but “anydata” where the schema is supplied somehow out of band faces the same issue.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 26 Jul 2015 17:49:17 +0000

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-masked] on behalf of
[email-masked]> wrote:

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

---

From: Lou Berger <[email-masked]>
Date: Sun, 26 Jul 2015 15:28:31 -0400

I completely agree.  We definitely will make use if this in the new models 
being developed in the routing area.

Lou

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Jul 2015 13:40:53 -0700

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

---

From: Lou Berger <[email-masked]>
Date: Sun, 26 Jul 2015 20:31:01 -0400

Andy,

Have you thought through implications / possibilities for existing models,  
e.g., interfaces?

Thanks,
Lou

On July 26, 2015 4:41:32 PM Andy Bierman <[email-masked]> wrote:

> ----------

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Jul 2015 23:18:38 -0700

On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <[email-masked]> 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.

Andy

>>> >> I agree, but this is what we are going to have. My proposal was to
>>> have
>>> >>just one with two different names.
>>> >>
>>> >> >
>>> >> >
>>> >> > >
>>> >> > >
>>> >> 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-masked]
>>> >
>>> >>wrote:
>>> >> > > >
>>> >> > > > > IMO #1 & #2 are really bad. I thought Y34-04 was essentially
>>> #3
>>> >>but it
>>> >> > > > > On the other hand, the only real contribution of "anydata"
>>> over
>>> >>"anyxml"
>>> >> > > > >  specified data model. The specification can be same or
>>> similar
>>> >>as
>>> >> > > > >  in yang-library.
>>> >> > > > >
>>> >> > > > > a single routing instance (i.e. without "routing-instance"
>>> list
>>> >>at the

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Jul 2015 16:53:55 +0200

> on the old docroot (not the new docroot ancestor).

The authors of DSDL family of schema languages realized the utility of
"compound documents" and designed NVDL language for their validation. It's
nicely described here:

http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compound.html

I think most of NVDL concepts could be applied to YANG, too, perhaps as
a part of external conformance specification.

As for XPath expressions, the specification could map each namespace to
a root that has to be prepended to every absolute XPath that starts with
a node from the given namespace. The existing modules could then
continue to work unchanged.

Actually, this is being done already now: when validating an XML
document containing YANG-modelled data, an initial segment often needs
to be prepended to all absolute XPaths, e.g. "/nc:rpc-reply/nc:data",
depending on the type of the document.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2015 17:09:46 +0200

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Jul 2015 11:48:37 -0400

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Jul 2015 09:58:15 -0700

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.

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 <[email-masked]> wrote:

>>>>> >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka <[email-masked]
>>>>> >
>>>>> >>wrote:
>>>>> >> > >
>>>>> >> > > We need something to model a container full of arbitrary YANG
>>>>> data
>>>>> >>nodes.
>>>>> >> > The payload of anyxml needn’t directly map to a data subtree in
>>>>> the
>>>>> >>usual sense.
>>>>> >> >
>>>>> >> > 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'
>>>>> >> > > > On Mon, Jul 20, 2015 at 5:48 AM, Ladislav Lhotka <
>>>>> [email-masked]>
>>>>> >>wrote:
>>>>> >> > > >
>>>>> >> > > > > The draft states they want to reuse ietf-interfaces but
>>>>> their
>>>>> >>tree in
>>>>> >> > > > > fact is
>>>>> >> > > > >
>>>>> >> > > > >   +--rw device
>>>>> >> > > > >          +--rw info
>>>>> >> > > > > 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
>>>>> >> > > > > I know Y34 was already closed but I think it is more
>>>>> important
>>>>> >>to do
>>>>> >> > > > > example, the ietf-routing module could simply define the
>>>>> data
>>>>> >>model for
>>>>> >> > > > > more complex router implementations can graft it as a
>>>>> subtree
>>>>> >>under

---

From: Lou Berger <[email-masked]>
Date: Fri, 31 Jul 2015 12:46:49 -0400

Andy,

> 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

> On Mon, Jul 27, 2015 at 8:48 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>>
>>
>>     On Sun, Jul 26, 2015 at 5:31 PM, Lou Berger <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Andy,
>>
>>         Have you thought through implications / possibilities for
>>         existing models,  e.g., interfaces?
>>
>>
>>
>>     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,
>>         On July 26, 2015 4:41:32 PM Andy Bierman <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>>         Hi Acee,
>>>
>>>         On Sun, Jul 26, 2015 at 10:49 AM, Acee Lindem (acee)
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             <[email-masked] <mailto:[email-masked]>
>>>             on behalf of
>>>             [email-masked]
>>>             <mailto:[email-masked]>> wrote:
>>>
>>>             >Lada,
>>>             >
>>>             >> > On 20 Jul 2015, at 19:29, Andy Bierman
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>             >> >
>>>             >> >
>>>             >> >
>>>             >> > On Mon, Jul 20, 2015 at 10:15 AM, Ladislav Lhotka
>>>             <[email-masked] <mailto:[email-masked]>>
>>>             >>wrote:
>>>             >> >
>>>             >> > > On 20 Jul 2015, at 17:00, Andy Bierman
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>             >> > >
>>>             >> > >
>>>             >> > >
>>>             >> > > On Mon, Jul 20, 2015 at 6:08 AM, Ladislav Lhotka
>>>             <[email-masked] <mailto:[email-masked]>>
>>>             >>wrote:
>>>             >> > >
>>>             >> > > > On 20 Jul 2015, at 14:55, Andy Bierman
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>             >> > > >
>>>             >> > > > Hi,
>>>             >> > > >
>>>             >> > > 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.
>>>             >> >
>>>             >> >
>>>             >> I agree, but this is what we are going to have. My
>>>             proposal was to have
>>>             >> > 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'
>>>             >> > > But a single container called "whatever" provides
>>>             no such
>>>             >>aggregation.
>>>             >> > The parent node can be a list as well. The “root”
>>>             node would be like
>>>             >> > 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
>>>             >> 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-masked] <mailto:[email-masked]>>
>>>             >>wrote:
>>>             >> > > >
>>>             >> > > > > On 20 Jul 2015, at 14:45, Ladislav Lhotka
>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>             >> > > > >
>>>             >> > > > > Hi,
>>>             >> > > > >
>>>             >> > > > > draft-rtgyangdt-rtgwg-device-model-00 at RTGWG
>>>             session, I am
>>>             >>wondering
>>>             >> > > > > The draft states they want to reuse
>>>             ietf-interfaces but their
>>>             >>tree in
>>>             >> > > > > fact is
>>>             >> > > > >
>>>             >> > > > >   +--rw device
>>>             >> > > > >          +--rw info
>>>             >> > > > > So the "interfaces" container is no more a
>>>             top-level node.
>>>             >>There are
>>>             >> > > > > three possible options:
>>>             >> > > > >
>>>             >> > > > > 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
>>>             >> > > > > 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
>>>             >> > > > > - Rename "anydata" as a synonym to "anyxml",
>>>             and deprecate
>>>             >>"anyxml" (but
>>>             >> > > > > - 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.
>>>             >> > > > >
>>>             >> > > > > 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
>>>             >> > > > > [email-masked] <mailto:[email-masked]>
>>>             >> > > > [email-masked] <mailto:[email-masked]>
>>>             >> > [email-masked] <mailto:[email-masked]>
>>>             >> [email-masked] <mailto:[email-masked]>
>>>             >[email-masked] <mailto:[email-masked]>
>>>             [email-masked] <mailto:[email-masked]>
>>>         [email-masked] <mailto:netmod%40ietf.org>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Jul 2015 12:05:39 -0700

> course, any proposed changes/approaches would be brought to the WG for
OK -- send an email invite to the meeting.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 1 Aug 2015 08:51:50 +0200

> I think it would be really good to explore other, less "disruptive"

I think the first step is to find out whether there is a problem worth
to be fixed. Why are the RFCs in question broken? (Yes, I have read
the openconfig IDs, I listened to the virtual interim meetings, I
assume you have read draft-bjorklund-netmod-openconfig-reply.)

Lets get the core of the openconfig argument on the table why the
existing RFCs are flawed.

/js