Subject: Fwd: I-D Action: draft-rtgyangdt-rtgwg-device-model-02.txt

From: Lou Berger <[email-masked]>
Date: Mon, 15 Feb 2016 09:59:03 -0500

FYI - This has been out a little bit, but haven't seen any comments.
We'd definitely like to hear from the WG on this.

quoting the draft:
   This version is a major
   change from the prior version and this change was enabled by the work
   on the previously mentioned Structural Mount/YSDL.

Note that an interim on Structural Mount/YSDL (which I think of
generally as 'schema mount') has been scheduled by the netmod WG -- see
http://www.ietf.org/mail-archive/web/netmod/current/msg15257.html and
http://www.ietf.org/mail-archive/web/netmod/current/msg15260.html

Lou

-------- Forwarded Message --------
Subject: I-D Action: draft-rtgyangdt-rtgwg-device-model-02.txt
Date: Fri, 22 Jan 2016 05:16:07 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Network Device YANG Organizational Models
        Authors         : Acee Lindem
                          Lou Berger
                          Dean Bogdanovic
                          Christan Hopps
	Filename        : draft-rtgyangdt-rtgwg-device-model-02.txt
	Pages           : 36
	Date            : 2016-01-22

Abstract:
   This document presents an approach for organizing YANG models in a
   comprehensive structure that may be used to configure and operate
   network devices.  The structure is itself represented as a YANG
   model, with all of the related component models logically organized
   in a way that is operationally intuitive, but this model is not
   expected to be implemented.  The identified component modules are
   expected to be defined and implemented on common network devices.

   This document also defines two modules that can be used to model the
   logical and virtual resource representations that may be present on a
   network device.  Examples of common industry terms for logical
   resource representations are Logical Systems or Routers.  Examples of
   of common industry terms for virtual resource representations are
   Virtual Routing and Forwarding (VRF) instances and Virtual Switch
   Instances (VSIs).

   This document is derived from work submitted to the IETF by members
   of the informal OpenConfig working group of network operators and is
   a product of the Routing Area YANG Architecture design team.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-rtgyangdt-rtgwg-device-model-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: t.petch <[email-masked]>
Date: Fri, 26 Feb 2016 12:08:43 +0000

Lou

I think that it is difficult, perhaps impossible, to review this I-D
until the foundations on which it is based, mount and op-state, become
firmer.

I track the discussions on the netmod WG list (and have done so since
before it existed!) and do not expect either of those two issues to
settle down in the immediate future.  Some aspects of YANG get agreed
quickly, others do not, and I see these two in the latter camp.

So for me,  the way to progress this I-D would be to join the netmod
list and advance those two topics.

Tom Petch

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: "Routing WG" <[email-masked]>
Sent: Monday, February 15, 2016 2:59 PM

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 26 Feb 2016 07:22:37 -0500

Tom,

I understand your comment wrt mount .  I think it is fair to suggest that 
having a net mod working group document on the topic be a gating item. Stay 
tuned. This sad, I hope that we can continue the discussion and identify 
any other possible issues for this working group.

I don't understand how the opstate discussion ties in.  Can you elaborate?

Thanks,
Lou

---

From: t.petch <[email-masked]>
Date: Fri, 26 Feb 2016 17:29:16 +0000

----- Original Message -----
From: "Lou Berger" <[email-masked]>
To: "t.petch" <[email-masked]>; "Routing WG" <[email-masked]>
Sent: Friday, February 26, 2016 12:22 PM

Lou

section 1
"   The top open issues are:

  1.  The use of YSDL vs Structural Mount, i.e., a Netmod defined
       Schema Mount solution, needs to be resolved as does ensuring that
       the selected approach has the needed capabilities.

  2.  This document will need to match the evolution and
       standardization of [OC-OPSTATE] or [NETMOD-OPSTATE] by
       the Netmod WG.
.............
"
Sounds like a Normative Reference to me (and as I said before, I still
see divergent views expressed on the Netmod WG list).

Tom Petch

> >>    logical and virtual resource representations that may be present
on
> > a
> >>    resource representations are Logical Systems or Routers.
Examples
> > of
> >>    of the informal OpenConfig working group of network operators
and
> > is

---

From: Christian Hopps <[email-masked]>
Date: Fri, 26 Feb 2016 14:30:54 -0500

> On Feb 26, 2016, at 12:29 PM, t.petch <[email-masked]> wrote:
> 
> From: "Lou Berger" <[email-masked] <mailto:[email-masked]>>
> To: "t.petch" <[email-masked] <mailto:[email-masked]>>; "Routing WG" <[email-masked] <mailto:[email-masked]>>

This actually doesn't feel contentious to me. The 2 solutions are very similar, and in fact good progress was made at the most recent interim with the 2 authors agreeing to work together. I don't believe I've seen anyone objecting to the concept of a mount whichever form it takes on the mailing list either.

>       standardization of [OC-OPSTATE] or [NETMOD-OPSTATE] by

We are simply stating the document needs to track the evolution of this. I don't believe there's anything in this draft that requires an opstate solution be chosen in order to review it. In fact if this were the case since op-state is targeted at *all* yang models, we would have to stop working on all models by this logic. :)

Thanks,
Chris.

---

From: t.petch <[email-masked]>
Date: Sat, 27 Feb 2016 16:09:58 +0000

---- Original Message -----
From: "Christian Hopps" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Lou Berger" <[email-masked]>; "Routing WG" <[email-masked]>
Sent: Friday, February 26, 2016 7:30 PM

> To: "t.petch" <[email-masked] <mailto:[email-masked]>>;
"Routing WG" <[email-masked] <mailto:[email-masked]>>
>> having a net mod working group document on the topic be a gating
item.
> Stay

We are simply stating the document needs to track the evolution of this.
I don't believe there's anything in this draft that requires an opstate
solution be chosen in order to review it. In fact if this were the case
since op-state is targeted at *all* yang models, we would have to stop
working on all models by this logic. :)

<tp>

Chris

It is described as an open issue so I take it as such, i.e. that the
draft cannot be finalised until the issue is; I have not been through
the I-D to see where the text depends on the outcome of the opstate
discussions (but find it plausible that it should) so it discourages me
from going further.

In passing, I doubt that opstate is targeted at all yang models; YANG
was around for a while before these particular requirements surfaced and
the I-D itself specifies a limited scope, namely "protocols and
functions defined within the IETF Routing Area".

Tom Petch

Thanks,
Chris.