Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

From: Lou Berger <[email-masked]>
Date: Tue, 18 Aug 2015 21:38:04 -0400

[Adding authors and RTG WG.]

Hi Andy,
    I'm not sure who you are looking to hear from as you addressed this
mail to the netmod list. I'm happy to give my opinion as it seems you
might have been aiming this at the draft authors.  (but then again
perhaps not.) 

On 8/18/2015 8:01 PM, Andy Bierman wrote:
> Hi,
>
> I assume this draft is what we should be reviewing and not
> the obsolete openconfig draft?

My personal view / hope is that the openconfig draft will be revised to
cover requirements while the DT draft  leads to an agreed upon approach
to addressing those requirements.  Again, just stating my view, not the
view of the DT, co-authors or OC draft authors.

>
>
> https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00
>
>
> Q1) scope
>
>
> sec 2:
>
>    The model organization can itself be thought of as a "meta-model",
>    in that it describes the relationships between individual models.  We
>    choose to represent it also as simple YANG model consisting of lists
>    and containers to serve as anchor points for the corresponding
>    individual models.
>
>    As shown below, our model is rooted at a "device", which represents a
>    network router, switch, or similar network element.  
>
>
> Why is this a meta-model?
because the aim to to show how other models inter-relate rather than
define the details of all models. As stated in the intro:

   This document aims to provide an extensible structure that can be
   used to tie together other models. It allows for existing, emerging,
   and future models. The overall structure can be constructed using
   YANG augmentation and imports.

> It looks like a real YANG data model where ad-hoc classification is
> being done
> using container names.

Sure, we're using YANG, or at least trying, to document our proposal. 
Do you think there's a better way to formally document the work?
 
>
> If vendors augment this tree with their own ad-hoc hierarchy, then how
> is this
> any better than what we have now?
>
This goes to requirements which is really in the scope of
draft-openconfig-netmod-model-structure.  From my perspective it comes
down to how much information is needed from an actual device in order to
come up with its yang-based configuration, and the principle that there
is benefit in this being minimized.  For example, consider the case
where a config is generated before a specific device is fielded or
perhaps even purchased/selected. But again, this more of a requirements
discussion.

> What is the scope of this work?
see slide 7 of
https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf

> It appears to be only for "routers switches or similar network elements".
>
>From the slide:
   From DT charter: An overall architecture for
   “the protocols and functionality contained inside the Routing Area”

> The hierarchy seems quite router-centric.
It is intended to be network device centric, routers, switches,
firewalls, etc.

> Is the expectation that all YANG-based devices will use this
> data hierarchy, or only some devices?
The proposal is to provide a framework for any device that supports a
protocol or other mechanism defined within the routing area.  (Or at
least that's our understanding of what we were asked to do.)

>
> Is the expectation that all YANG modules will use this
> data hierarchy, or only some modules? 

I personally think there will be siblings to /device, e.g., /service -
but this is beyond the scope of this draft.

> Is it just
> for IETF routing modules or more than that?
>
I think this is the same question and answer as above.

> Q2) interfaces
>
>    The interface model is taken from [RFC7223 <https://tools.ietf.org/html/rfc7223>] and includes possible
>    technology-specific augmentations using example technologies defined
>    in [RFC7277 <https://tools.ietf.org/html/rfc7277>].
>   +--rw interfaces
>       |  +--rw interface* [name]
>       |     +--rw name                       string
>       |     +--rw bind-network-element-id?   uint8
>       |     +--rw ethernet
>       |     |  +--rw bind-networking-instance-name?   string
>       |     |  +--rw aggregates
>       |     |  +--rw rstp
>       |     |  +--rw lldp
>       |     |  +--rw ptp
>       |     +--rw vlans
>       |     +--rw tunnels
>       |     +--rw ipv4
>       |     |  +--rw bind-networking-instance-name?   string
>       |     |  +--rw arp
>       |     |  +--rw icmp
>       |     |  +--rw vrrp
>       |     |  +--rw dhcp-client
>       |     +--rw ipv6
>       |        +--rw bind-networking-instance-name?   string
>       |        +--rw vrrp
>       |        +--rw icmpv6
>       |        +--rw nd
>       |        +--rw dhcpv6-client
>
>
> Actually the interface model is quite different than the one in RFC 7223.
> Seems rather ethernet-centric.  I notice the "type" leaf was removed,
> along with everything else.  Is the plan to toss out RFC 7223,
> recharter the interfaces work, and start over?
>

So this may be our/my inexperience at play here.  I didn't think it
appropriate for a document that is augmenting an existing model to
redefine the current model - I actually thought this was part of the
power of YANG augmentation.  Are you saying we should have included the
whole 7223 model to augment it, or something different?

Also not the text says:
        ... possible technology-specific augmentations  using example
technologies ..
and

   The interfaces container includes a number of commonly used
   components as examples:

> Q3) virtual devices
>
>    The model supports the potentially independent system management
>    functions and configuration per logical network element. This
>    permits, for example, different users to manage either the whole
>    device or just the associated logical network element. 
>
> Sec 2.2.1 shows the system management tree but it is wrong.

Yes, good catch of a cut-and-past bug. thankfully it is correct both
immediately before in the section intro and the details

> The following tree is what the YANG model defines:
>  +--rw device
>           +--rw logical-network-elements
>                -rw logical-network-element* [network-element-id]
>                    +--rw network-element-id                  uint8
>                    +--rw network-element-name?               string
>                    +--rw default-networking-instance-name?   string
>                    +--rw system-management
>                    |  +--rw device-view?                      boolean
>                    |  +--rw syslog
>                    |  +--rw dns
>                    |  +--rw ntp
>                    |  +--rw statistics-collection
>                    |  +--rw ssh
>                    |  +--rw tacacs
>                    |  +--rw snmp
>                    |  +--rw netconf
> What about devices that do not have logical network elements?
It would have only a single network-element-id

> This hierarchy may be appropriate for very large routers
> but nothing else.
The intent is to cover all implementations independent of vendors.  We
had a good range of view points both in the DT and in the RTGWG
discussion.  Not saying there was full agreement, just that we have a
proposed starting  point.

> How can this tree represent both the physical view and the virtual view?
Are you referring to section 2.3?  If so, I think we all agree (and said
as much in Prague) that this section could be clearer.  We/I tried to
explain it in the Prague slide 25 (for this you may want to see the
animation in
https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx)

Basically the amount of information provided depends on the
logical-network-element context used to access this information.  So if
a model is "retrieved" via an IP address associated with a
network-element-id  with device-view=true (e.g., the left side of slide
25), then the device's full view is provided.  And when a model is
"retrieved" via an IP address associated with a network-element-id  with
device-view=false (e.g., the ride side of slide 25, either color) only
information related to the network-element-id is provided.

> It seems to assume this is the "root user physical view".
> Please explain how device-type=VIRTUAL is used.

This is a bit different and hasn't been a major point of discussion in
the WG -- we brought this over from the openconfig draft.  I read this
as being pretty uninteresting and simply set based on if the device is
running on dedicated special purpose h/w (e.g, a classic
"name-your-vendor" router) or as a VM (aka NFV).  I'll defer to the OC
or other DT folks if their opinion differs.

Thanks for the comments/discussion!

Lou

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Aug 2015 11:27:30 +0200 (CEST)

Hi,

> Do you think there's a better way to formally document the work?

I can see two approaches:

  1) Define a YANG module with the structural hierarchy.  Then
     other modules augment this module at the correct place in the
     hierarchy.  This module will probably be updated pretty often,
     especially if the idea to have ONE module with the complete
     hierarchy for ALL types of devices.

     A variant is to define such a module for routing-specific modules
     only to augment.  Other areas can define similar "structural"
     modules.

  2) Document the hierarchy as a guideline.  When it is time to work
     on a new module, lets say mpls, we look into this guideline and
     define the necessary hierarchy in the mpls module.

> perhaps even purchased/selected.

As long as the device implements standard data models, why does it
matter for pre-provisioning if the standard path to configure an
interface is /devices/interfaces/interface or /interfaces/interface?

>    “the protocols and functionality contained inside the Routing Area”

But the design you propose has huge impact on all models, also models
from other areas.

> whole 7223 model to augment it, or something different?

As long as you want to have /device/interfaces, you need to obsolete
the model in RFC 7223 (and all other published YANG models) and
rewrite them.  However, if we get rid of the /device container, the
existing model in RFC 7223 fit in nicely in your hierarchy.

I think many of us have said this before, but the top-level container
/device doesn't really solve any problem.  Suppose we have a module
today with a top-level node /FOO.  Why would this module work better
if it augemented /device to give /device/FOO?

Maybe the problem you are trying to solve with "/device" is what is
written in section 3.1:

   One of the challenges in assembling existing YANG models is that they
   are generally written with the assumption that each model is at the
   root of the configuration or state tree.  Combining models then
   results in a multi-rooted tree that does not follow any logical
   construction and makes it difficult to work with operationally.  In
   some cases, models explicitly reference other models (e.g., via
   augmentation) to define a relationship, but this is the case for only
   a few existing models.

First of all I don't really agree with this.  We just have a few
module published, but for example ietf-ip augments ietf-interfaces,
and the idea with ietf-routing is that routing-specific modules
augment it.  In fact, I think the published modules follow your
proposed hierarchy (with some exception) - if it wasn't for the
/device node.

Second, if we want to be conservative with top-level nodes (I am not
convinced that this is a problem) we can solve that without going into
the extreme of having *one* top-level node.  Instead of having N
top-level nodes, we would have N nodes under /device.  Why is this
better?

> information related to the network-element-id is provided.

Do you want the user from a particular IP address to have access to
just his part of the tree, or do you want that user to have his own
"sandbox" that he can control independently of other users?

In the first case, you can use NACM to set up rules to give each user
proper access (based on user identity rather than IP address though).
You don't need this "device-view" in order to do this.

In the latter case, I don't think the proposed design works.  (I can
go into details if it turns out that this what you had in mind).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Aug 2015 20:04:03 -0700

> might have been aiming this at the draft authors.  (but then again
Tom sent the meeting invite to netmod so I figured that was where we were
supposed to discuss drafts.

> view of the DT, co-authors or OC draft authors.
Sort of confusing because this draft says it is based on the other draft,
so one assumes it is meant to replace it.

>    YANG augmentation and imports.
OK -- the YANG modules themselves should say how they
relate to each other.  I guess you mean the logical-network-element
and other framework nodes.

> Do you think there's a better way to formally document the work?

So this document is not the actual set of NP containers
that all YANG modules are supposed to augment?
It would help to understand how the tree will be managed
and maintained over time.

> perhaps even purchased/selected. But again, this more of a requirements

If a vendor has their own proprietary protocol or HW type,
where does it go in the tree?  The set of modules used for some
function may not be coupled to one node in the data tree.

But it is OK if this is out of scope.
It is no different than any other standard module that a vendor
could augment with proprietary data.

> It is intended to be network device centric, routers, switches,

So what is the plan for YANG modules that are not specific to these devices?
For example, some modules like interfaces and NACM could be
implemented on any platform, even constrained devices
(maybe running CoMI over CoAP).

> least that's our understanding of what we were asked to do.)

I understand the value of finding data via familiar keywords.
(The CLI never went away -- it just grew angle brackets ;-)
It is useful to be able to debug with nothing more than a
WEB browser and URLs typed by hand. I could never remember
a single SNMP OID but YANG data is easy to remember.

>From the start, the NETCONF and NETMOD WGs rejected
attempts at data organization because it should not matter
to a programmatic API.

> >    The interface model is taken from [RFC7223 <
> https://tools.ietf.org/html/rfc7223>] and includes possible

 I did not find any augment statements in model-structure.yang.

You have to augment /interfaces, not /device/interfaces,
if you are using RFC 7223.

> information related to the network-element-id is provided.

IMO this logical structure should not be part of data hierarchy itself,
since it does not apply to all devices.

YANG does not provide a way for the hierarchy to be
one way for the physical view and another for
a virtual view. The same /path/to/data is seen by both.
Is this really what you want?

> or other DT folks if their opinion differs.

Each virtual view sees its own slice of the physical device as an
entire device, not as 1 entry in a more complex model.

IMO it would be better to define a separate data structure and
tag it as a special nested datastore root.  (e.g. YANG mount).

Maybe this would work:

  container virtual-devices {
     list virtual-device {
        key device-id;
        ...
        container device {
            // same data models as the /device contents
         }
     }
  }

  container device { ... }

Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 19 Aug 2015 08:48:28 -0400

> On Aug 18, 2015:9:38 PM, at 9:38 PM, Lou Berger <[email-masked]> wrote:
> 
> cover requirements

	Can you be specific about which requirements you feel are not covered ?

	—Tom

> while the DT draft  leads to an agreed upon approach

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 19 Aug 2015 08:54:19 -0400

> On Aug 18, 2015:11:04 PM, at 11:04 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, Aug 18, 2015 at 6:38 PM, Lou Berger <[email-masked] <mailto:[email-masked]>> wrote:

	The meeting invite was to get peoples’ attention and ask that people start planning ahead.
However, please discuss here ahead of time. 

> > https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 <https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00>
> >
> >
> > Q1) scope
> >
> >
> > sec 2:
> >

	Its useful if these sorts of things are added to the requirements.

> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf <https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf>
> 

	Again, good to add to the requirements document.  Backwards compatability is something
we must address; we are unlikely to go forward with a plan that obsoletes everything
that exists today - or at least without a plan to move those things forward.

> attempts at data organization because it should not matter

	It does not matter technically speaking, but I think the thing the operators
are saying here is that if its organized in this specific way, it not only makes
their lives easier, it allows them to do things better/less expensively.  That
seems important.

> >    The interface model is taken from [RFC7223 <https://tools.ietf.org/html/rfc7223 <https://tools.ietf.org/html/rfc7223>>] and includes possible
> >    in [RFC7277 <https://tools.ietf.org/html/rfc7277 <https://tools.ietf.org/html/rfc7277>>].
> >   +--rw interfaces
> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx <https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx>)
> 

	This is an important issue to get to the bottom of.  Is this in the
requirements?

> Is this really what you want?

	Please add (or not) to the requirements.

> Thanks for the comments/discussion!

	It seems there are a number of things that should be teased out here as issues that we can come to a
consensus on.  Some of these things do not appear in the requirements. Can we get those in there
if we agree on them?  The others we could track as issues.

	—Tom

> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Aug 2015 20:40:43 +0200

>    YANG augmentation and imports.

You can easily extract relationships between YANG data models out of
YANG language constructs such as import relationships, leafref path
restrictions, augment references, etc.

- Why do you think relying on language constructs does not work?

- Why do you believe that relying on a certain hierarchy that several
  independent SDOs and vendors have to augment and fill consistently
  is going to be lead to a robust solution?

If YANG adoption continues as it looks right now, we will count
modules in the thousands in a couple of years originating from many
different organizations. I would trust tools that are able to
interpret YANG language constructs to scale up to such a scenario. I
doubt a simple hierarchy of containers (which will essentially become
unmaintainable once it is used by several standards) will be of much
value in 10+ years.

Andy's early work on YANG packages that provide machine readable
meta-data is a useful direction to explore further.

/js

PS: As a spare-time Unix system administrator, I recall several fancy
    proposals back in the 1990's how to best organize your /usr/local
    to make software installation and sharing easy. It seems none of
    these approaches that are essentially relying on naming
    conventions succeeded in the long run. Instead, we got software
    package systems that have sufficient machine readable
    meta-information to make software management easy and reliable.

-- 
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: Andy Bierman <[email-masked]>
Date: Wed, 19 Aug 2015 11:54:29 -0700

> meta-data is a useful direction to explore further.

I took the conformance stuff out of the YANG packages draft because
there were concerns before that it conflicted with YANG module
conformance.

It seems like the "augment with mandatory nodes" type of problem
indicates we need a conformance model that is capable of
describing an API that spans more than one YANG module.

Andy

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Aug 2015 22:00:22 -0400

sorry for the slow response -- on a bit of a vacation schedule aat the
moment...

> supposed to discuss drafts.

NP - just a bit odd to not list the folks you expect to answer on the to
line.

> and other framework nodes.

as well as the overall presented structure.

> and maintained over time.

I think we're open on this and this is a bit of the point of section 3.
 If you/the WG think there's a 'right' way to do this, we'd like to hear it.

> So what is the plan for YANG modules that are not specific to these devices?

If the module relates to something beyond device config, it would go
elsewhere, e.g. /services - but this is a question for the organization
of those models.

> (maybe running CoMI over CoAP). 

And the same is true for the device model

>     >    The interface model is taken from [RFC7223
>     <https://tools.ietf.org/html/rfc7223>] and includes possible
looks like a bug.

> if you are using RFC 7223.

Well this is certainly a part of the debate.  A bigger issue is actually
7317 (system management) which ends up deeper in the tree and,
consequently, just dropping /device doesn't solve anything.

> a virtual view.

again, I think you're mixing things here. Per slide 10 of
https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf
there's device-view which is used as part of representing things like
logical systems. and device type which is that the device may be VM or
hardware based and the device shouldn't really operate or be managed
differently.

> The same /path/to/data is seen by both.

Think so.

> entire device, not as 1 entry in a more complex model.
you're talking logical-network-element, right?

>             // same data models as the /device contents

If I understand your point, (although virtual-device =
logical-network-element) this is pretty close to what we discussed at
one point.  Two issues came up:
1- this implied, at least to us more substantive impact on the interface
model - some were in favor, but in the end the decision was to minimize
impact to the existing model.

2- where do unassigned resources go?  In the current proposal they are
simply unassigned, rather than needing to automatically show in a
'default' logical-network-element/device.

Probably worth discussing this further.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Aug 2015 22:23:15 -0400

Martin,

See below.
>      only to augment.  Other areas can define similar "structural"
Or device additions can augment the base model.

>      define the necessary hierarchy in the mpls module.

I think this is a good topic to discuss.  The second sounds lighter
weight as long as it is followed while the first makes it hard to not
follow. I see advantages in both.

> interface is /devices/interfaces/interface or /interfaces/interface?

I personally see the top level as more about logical separation of model
types/classes, like a top level directory structure.  So IMO it's a bit
subjective and really about establish and agreeing upon conventions. --
and there's a group of users who say they really like it one way.

Deeper in the hierarchy the path becomes more significant, but you
weren't really questioning this.

> But the design you propose has huge impact on all models, also models

A very fair point and why it's important to discuss in this WG.  No
discussion happened in the prague session largely due to multiple
scheduling conflicts.

> existing model in RFC 7223 fit in nicely in your hierarchy.

And this is certainly an important point, and I personally think we
should have a full discussion of if it's worth preserving RFC 7223 or
open the door for changing  it.  We had many discussions on this in the
DT and while multiple wanted to do an even larger change, in the end the
consensus was to try minimize impact to the this and other RFCs -- even
if it meant using somewhat more cumbersome mechanisms.

> if it augemented /device to give /device/FOO?

as mentioned above, I personally think this is about logical separation
of model types/classes, like a top level directory structure.  So IMO
it's a bit subjective and really about establish and agreeing upon
conventions. -- and there's a group of users who say they really like it
one way.

> the extreme of having *one* top-level node.  

Why do you say only one top level node.  This isn't my exception, nor do
I see this stated in the draft.  I do think we say one top level node
dealing with device configuration.

> Instead of having N

N would contain only device configuration related modules.  There could
be others, e.g., /services has been mentioned by some.

> "sandbox" that he can control independently of other users?

The intent was multiple logical-network-elements and when
device-view=false, any management operation taking place in the context
of that LNE would only have visibility and ability to control that LNE.
 This matches a pretty common feature set.

> proper access (based on user identity rather than IP address though).

I think this would be used too.  For example user1 would have ro access
while user2 has rw.

> You don't need this "device-view" in order to do this.
Agreed, but this is something different and matches how a multiple
devices from multiple vendors function today.

> go into details if it turns out that this what you had in mind).
I think we're interested in a form of the first.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Aug 2015 22:31:11 -0400

> 	Can you be specific about which requirements you feel are not covered ?

I wasn't commenting on what's covered/not covered.  I was saying that I
don't think the openconfig draft should disappear, rather it should be
revised to just  focus on requirements.

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Aug 2015 09:58:53 +0200 (CEST)

Lou Berger <[email-masked]> wrote:
> types/classes

This then sounds like meta data about the model.  What kind of model
is it - see draft-bogdanovic-netmod-yang-model-classification.

I don't think it is a good idea to encode meta data into the data
hierarchy.  It would be better IMO to keep this either inline in the
module definition (yang-model-type device;) or externally in a
separate registry.

> like a top level directory structure.  So IMO it's a bit

I am all for significant nodes in the path!  My point is that /device
is insignificant.

> conventions. -- and there's a group of users who say they really like it

Hopefully, a decision to change all existing models (including vendor
models!) will be based on something more technical than the fact that
a group of people "really like it" some other way.

> dealing with device configuration.

In light of what you explained, I can rephrase this:  On any given
implementation there will always only be one top-level node.  For
example, on a device, the top-node is always /device.  Correct?

>  This matches a pretty common feature set.

Ok, so this means that there is still just one configuration for all
logical-network-elements, right?  E.g., if a user from
logical-network-element A locks the datastore, he will lock out a
user from logical-network-element B; if user from A saves running to
startup changes for B will also be saved, etc?

/martin

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 20 Aug 2015 08:34:30 -0400

> On Aug 19, 2015:10:31 PM, at 10:31 PM, Lou Berger <[email-masked]> wrote:
> 

	Fair enough.

	—Tom

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Aug 2015 22:53:55 -0400

Martin,
	Sorry for the delayed response, was away for a bit.  Not sure if any of
this is OBE as just starting to catch up on mail.

> is it - see draft-bogdanovic-netmod-yang-model-classification.

Perhaps.  I'll defer to Dan on this as he's also a co-author/DT member.

> I am all for significant nodes in the path!  

This is really good/useful to hear.  If disagreement is limited to the
top level node, it's much easier (but not easy ;-) problem to solve.

> My point is that /device

I think the fundamental discussion here, is who get's to say what's
significant and we have (at least) two opposing views on this point.

>From my standpoint it comes down to how you view full set of models that
may be seen.  From the device view, you might only (or, more likely,
mostly) see models under /device -- so device doesn't add much value.
BUT from the controller/NMS/EMS (or whatever you want to call it) view,
you're likely to see all the models so /device plays a much more
significant role in identifying logical model
organization/understanding.  -- That said, I'm much more of a device
person than an NMS builder, so I'm also willing to trust the opinion of
folks who are clearly doing significant work on the controller/NMS side.

> a group of people "really like it" some other way.

I'm equally unsure that having an argument of "I got there first" is a
compelling argument given the number of folks (including vendors) who
have stated willingness (or even support) for change.  I think having a
major class of users stand up and say this is important should garner
some notice.
-- In the end, this is largely a (I think) netmod WG decision.

> example, on a device, the top-node is always /device.  Correct?

I don't think this will always be the case for *all* devices, but it may

> startup changes for B will also be saved, etc?

If A (or B) has device-view=true, I think so.  If both have
device-view=false, I suspect this may be implementation specific, but am
not sure.

Lou

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Aug 2015 09:41:26 +0000

On 8/26/15, 2:40 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote:
>
>Please keep in mind that we are talking about several published
>proposed standards that have been implemented and deployed. I think
>there must be convincing technical reasons to declare them broken and
>to redo them.

Other than adding /device at the top, we are not obsoleting RFC 7223. The
current device model keeps the interfaces configuration silo and merely
augments it with a binding to the logical-networking-element.

Thanks, 
Acee

---

From: Lou Berger <[email-masked]>
Date: Wed, 26 Aug 2015 05:51:55 -0400

> there must be convincing technical reasons to declare them broken and

As Acee says, we have been trying very hard to minimize any impact to 
existing work even when the result is suboptimal. I also agree that  
changing PS RFCs should not be done without serious consideration. That 
said, the IETF process does permit updates and replacements based on WG and 
IETF consensus -- which is not quite the same as your last statement.

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Aug 2015 12:26:00 +0200 (CEST)

"Acee Lindem (acee)" <[email-masked]> wrote:
> Other than adding /device at the top, we are not obsoleting RFC
> 7223.

This doesn't make sense.  The YANG model is the contract.  You are
proposing changing the contract.  The fact is that you will be
obsoleting 7223 (and the other RFCs).  Existing devices and
applications will have to change in order to handle this new top-level
node (which will be in some other namespace I presume, unless your
proposal is one gigantic monolithic model).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Aug 2015 12:41:29 +0200 (CEST)

> >>> Lou Berger <[email-masked]> wrote:

[...]

> you're likely to see all the models

Agreed, but see below.

> so /device plays a much more

[This was briefly discussed in another mail thread, and I'll repeat it
here.]

On the controller, you probably have a list of devices you control
(this is how our NCS works, and how ODL works (I have been told)):

  container devices {
    list device {
      key name;
      // meta-info about the device goes here, things like
      // ip-address, port, auth info...
      container data {
        // all models supported by the devices are "mounted" here
      }
    }
  }

So on the controller, the path to interface "eth0" on device "foo"
would be:

  /devices/device[name='foo']/data/interfaces/interface[name='eth0']

if we also have a top-level "/device" container we'd have:

  /devices/device[name='foo']/data/device/interfaces/interface[name='eth0']

(here you again can see that the "device" node in the device model
doesn't make much sense)

The path is scoped in the system you work with; in the controller it
might be as I illustrated above, in the device it starts with
/interfaces.  But then you might also have a
controller-of-controllers. where the path might be:

  /domains/domain[name='bar']/devices/device[name='foo']/data
    /interfaces/interface[name='eth0']

Pushing all these concepts down into the device model clearly doesn't
help...

/martin

---

From: Lou Berger <[email-masked]>
Date: Wed, 26 Aug 2015 06:58:46 -0400

On August 26, 2015 6:24:19 AM Juergen Schoenwaelder 
<[email-masked]> wrote:

> On Wed, Aug 26, 2015 at 09:41:26AM +0000, Acee Lindem (acee) wrote:
>>
>>
> For the sake of clarity, these are the YANG data models that are
> published as Proposed Standard RFCs:
>
> - RFC 6022 NETCONF Monitoring
> - RFC 6536 NETCONF Access Control Model
> - RFC 7223 Interface Management
> - RFC 7277 IP Management
> - RFC 7317 System Management
> - RFC 7407 SNMP Configuration
>
> I see text in draft-rtgyangdt-rtgwg-device-model-00 that seems to
> affect pretty much all of them.

Agreed. Although we're proposing reusing / rehoming them.

> I also do not see "augments it (RFC
> 7223) with a binding to the logical-networking-element" in the YANG
> fragment in draft-rtgyangdt-rtgwg-device-model-00.
>

This omission has been pointed out before.  We need to fix that.

Lou

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 26 Aug 2015 07:33:01 -0400

> On Aug 26, 2015:5:51 AM, at 5:51 AM, Lou Berger <[email-masked]> wrote:
> 
> 
> 
> On August 26, 2015 2:42:26 AM Juergen Schoenwaelder <[email-masked]> wrote:
> 
> As Acee says, we have been trying very hard to minimize any impact to existing work even when the result is suboptimal. I also agree that  changing PS RFCs should not be done without serious consideration. That said, the IETF process does permit updates and replacements based on WG and IETF consensus -- which is not quite the same as your last statement.
> 
> Lou

	[Speaking for myself]

	Is the resistance to this proposal because of the actual changes to structure, or is it a resistance to churn/change? And if we solved the latter by say relaxing the rules around how we progress models to PS, would this alleviate the concerns for the former?  The meta question I will ask is: is the existing RFC process adequate/sufficient for us to move forward on such a large scale with Yang models at the IETF?  Other organizations currently iterate on models using certain revision conventions (that are consistent with the rules we put out here) yet produce multiple versions of the same model within the same year.  As a matter of fact, multiple versions are allowed to coexist within a single implementation.  In stark contrast, the M.O. at the IETF has been to treat Yang models much like we did SNMP MIBs (or any other document here) thereby assuming that once it becomes an RFC, that it is largely set in concrete for many years to come.
 
	—tom

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

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 26 Aug 2015 07:35:21 -0400

> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund <[email-masked]> wrote:
> 

	Again I will ask: why is this bad?  Obviously the implementation will have to 
evolve to the new models, but is this relatively static model where we really want to 
get to simply because some device vendors/server vendors find it a pain to iterate
models to support the latest versions?  Again, others have figured out how to do this
much more rapidly.  In the past we have seen what happens to things that cannot evolve
fast enough...

	—Tom

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Aug 2015 13:58:23 +0200 (CEST)

Nadeau Thomas <[email-masked]> wrote:
> 	[Speaking for myself]
> 
> 	Is the resistance to this proposal because of the actual changes to
> 	structure, or is it a resistance to churn/change?

The former.  IMO this is technically not a good proposal, as I have
tried to explain several times.

>       And if we solved the
> 	latter by say relaxing the rules around how we progress models to PS,
> 	would this alleviate the concerns for the former?  The meta question I
> 	will ask is: is the existing RFC process adequate/sufficient for us to
> 	move forward on such a large scale with Yang models at the IETF?
> 	Other organizations currently iterate on models using certain revision
> 	conventions (that are consistent with the rules we put out here) yet
> 	produce multiple versions of the same model within the same year.  As
> 	a matter of fact, multiple versions are allowed to coexist within a
> 	single implementation.  In stark contrast, the M.O. at the IETF has
> 	been to treat Yang models much like we did SNMP MIBs (or any other
> 	document here) thereby assuming that once it becomes an RFC, that it
> 	is largely set in concrete for many years to come.

In this specific case the change is cosmetic but has disastrous
effects on other standard modules, other vendor-specific modules,
existing server code and existing client code.  I think people expect
IETF standards to be a bit more stable than that.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Aug 2015 14:09:18 +0200 (CEST)

Nadeau Thomas <[email-masked]> wrote:
> 	Again I will ask: why is this bad?

My point above was in reply to the statement that "we are not
obsoleting RFC 7223" [because the change is so small?] - you would in
fact be obsoleting the model in 7223.

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Aug 2015 13:09:44 +0000

On 8/26/15, 8:09 AM, "Martin Bjorklund" <[email-masked]> wrote:

>> >>>> have stated willingness (or even support) for change.  I think
>>having
>> >>>> a

There have been other mechanisms discussed to relocate YANG models.
Perhaps, one of these could be employed in lieu of obsoleting the existing
models. 

Thanks,
Acee

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 26 Aug 2015 09:17:03 -0400

> On Aug 26, 2015:7:58 AM, at 7:58 AM, Martin Bjorklund <[email-masked]> wrote:
> 

	Therein lies the salient part of question I am asking: is this really 
the case these days?  The operators seem to be providing an answer that contradicts
this age-old assumption. Other projects like ODL are too.  Both have real
deployments too - these reference points are not science projects. I think its
fair to bring this specific issue out in the open here to discuss because its
a real issue we need to solve not just here in NETMOD, but at the IETF 
in general.

	—Tom

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 26 Aug 2015 09:19:43 -0400

> On Aug 26, 2015:8:09 AM, at 8:09 AM, Martin Bjorklund <[email-masked]> wrote:
> 

	The flip side to this is that while you evolve the model 
in 7223, you evolve it rapidly and to conform to the newer model(s).
The older model does actually still exist, and if we have a way to
refer back to it its not really obsolete; its just an older revision.

	—Tom

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2015 06:34:11 -0700

> a real issue we need to solve not just here in NETMOD, but at the IETF

YANG modules are not relocatable.
The issue should be really clear to anybody who has to support product
in the field.  If you make this change, the existing products stop working.
It doesn't matter if you move the YANG objects a little or a lot.

Since the proposed change ( / to /device ) adds no value whatsoever
to a programmatic interface, the product in the field will be broken
for no real reason.

If vendors are expected to move all their YANG objects into some
uber-tree that the IETF owns, then the disruption is total.

I agree the NETMOD WG should think carefully about this change
before agreeing to it, but it is the equipment vendors who will
pay for it.

Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 26 Aug 2015 09:34:57 -0400

> On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

	This is exactly what I want to get on the table.  If we can agree
on a mechanism/s to do relocate modules, then this might alleviate the
resistance to evolve models. The current issue aside, if you step back and look 
at the wider IETF situation around all the Yang models being created and
are RFCs, and the dependency graph that is created. You can then 
imagine a time after that point when others come along that evolve 
parts or entire modules.  We currently refer to this as “obsoleting”
all of the modules that it depends on, which is a very big problem using
the current RFC process.  Not only does it require a revision of all those
RFCs (due to obsoleting the previous ones) - and thus all the procedural/management
overhead that will incur - but the time lag from start to finish. And
this might happen for any new module. This is not scaleable going forward.

	—Tom

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2015 06:54:39 -0700

On Wed, Aug 26, 2015 at 6:34 AM, Nadeau Thomas <[email-masked]>
wrote:

> >>>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund <[email-masked]
> >
> >>>> wrote:
> >>>>

This shows a rather diminished understanding of how YANG works.
YANG defines data at a specified location /some/path/from/root.
Protocols like HTTP can deal with moved resources (e.g., 301).

> this might happen for any new module. This is not scaleable going forward.
So we would just need to retrofit all the clients and servers with
complicated
code to relocate YANG modules and adjust all the validation tests?

Another approach is to not rely so heavily on one giant uber-tree
that MUST be correct on the first try and never change.
Resource directories and other flexible approaches have been developed
for this purpose.

Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Wed, 26 Aug 2015 11:19:34 -0400

> On Aug 26, 2015:10:51 AM, at 10:51 AM, Kent Watsen <[email-masked]> wrote:
> 
> 
> 
> I agree that an uber tree stands to make things worse.  

	This seems to be the case the more we think through this.

> Distinct modules have distinct namespaces and no collisions concerns.   But even better than that, distinct modules promote competition.  

	Or simply multiple versions of the same modules at the same time. ODL lets you do this, for example, and happily works.  But the other more IETF-related situation is as you say, if there are two draft models for the same features.  One could and should 
be able to run them together, for at least experimental purposes. 

> I have no issues with there existing modules with overlapping concerns, even when implemented simultaneously by the same server.  I'm projecting, but it seems that the uber tree approach would put a freeze to such experimentation, which is fine for a specific project to hoist onto itself, but seems inappropriate for a standards organization.  Again, I like the idea of relocatable modules, as it seems to allow coexistence of both options.

	I agree.

	Tom  (as individual).

> Kent // as a contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Aug 2015 08:40:31 +0200

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Aug 2015 12:23:37 +0200

I see text in draft-rtgyangdt-rtgwg-device-model-00 that seems to
affect pretty much all of them. I also do not see "augments it (RFC
7223) with a binding to the logical-networking-element" in the YANG
fragment in draft-rtgyangdt-rtgwg-device-model-00.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 26 Aug 2015 14:51:44 +0000

> that MUST be correct on the first try and never change.

I agree that an uber tree stands to make things worse.   Distinct modules have distinct namespaces and no collisions concerns.   But even better than that, distinct modules promote competition.  I have no issues with there existing modules with overlapping concerns, even when implemented simultaneously by the same server.  I'm projecting, but it seems that the uber tree approach would put a freeze to such experimentation, which is fine for a specific project to hoist onto itself, but seems inappropriate for a standards organization.  Again, I like the idea of relocatable modules, as it seems to allow coexistence of both options.

Kent // as a contributor

---

From: Lou Berger <[email-masked]>
Date: Wed, 26 Aug 2015 15:18:02 -0400

Martin,

> [This was briefly discussed in another mail thread, and I'll repeat it
Thanks.

> (here you again can see that the "device" node in the device model

if there are siblings, it could still make sense...

> Pushing all these concepts down into the device model clearly doesn't

So, I think it would be good to hear from the openconfig folks on this
point.  Perhaps they'll respond via e-mail, perhaps it'll have to wait
for the interim...

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 26 Aug 2015 15:33:05 -0400

Tom,

On 8/26/2015 9:34 AM, Nadeau Thomas wrote:
> ...
> 	This is exactly what I want to get on the table.  

So taking a step back, perhaps there is a YANG language question at the
heart of this discussion.  I think we're seeing cases where the same
data model is useful in multiple cases/places.  The example I like to
use (although I know others disagree with the example) is the case of
PE/CE config information, where some of the exact same information may
end up on the CE and PE devices as well as the L3 service model.  In
this case we'd like a core model to be "included" (or "linked") into two
larger models.  Importantly, I'm referring to doing this as part of
model definition - not at server/device run time.  This is important for
the pre-provisioning case. 

It is my understanding that there is no way to really do this in a
general and extensible way (including allowing for augmentations)
today.  If there was such support, I do think we'd be saying that we'd
like the existing models to support this mechanism rather than our
current proposal of being relocated . 

Lou
(BTW this is my opinion, not speaking for the DT.)

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2015 12:48:03 -0700

> current proposal of being relocated .
If you are talking about schema reuse, then YANG has groupings as the
solution.
But it seems you are talking about YANG Mount -- the ability to have a
subtree on server X represent a different subtree on server Y.  On the
controller
the 'mount point' is not the actual data root (as Martin has explained).
On the NE, the data models are in their real location  On the controller
they are not.

This can be done with an 'anyxml' hack today.
It would be better to have real YANG support for this very basic
use-case for YANG Mount.

Andy

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2015 07:13:16 -0400

On 08/26/2015 03:48 PM, Andy Bierman wrote:
> 
> 
> On Wed, Aug 26, 2015 at 12:33 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Tom,
> 

My understanding is that the usage scope of groupings is pretty limited
and not really suitable for complex (sub)tree/module representation.
Also groupings can't be augmented

> use-case 

I think finding a yang-based solution (to reuse) would be helpful.

Lou

> for YANG Mount.