Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

From: Balazs Lengyel <[email-masked]>
Date: Fri, 1 Dec 2017 12:23:24 +0100

Hello,

container interfaces-state  is deprecated. I assume that if a container 
or list is deprecated, then all its contents are also deprecated.  Is 
there a need to mark all leafs deprecated too?

regards Balazs

On 2017-11-28 20:29, Kent Watsen wrote:
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-rfc7223bis-00.
>
> Please recall that this update's intention is to
> modify the YANG module to be in line with the NMDA
> guidelines [1].  Reviewing the diff between the two
> drafts [2] should reveal just this.
>
> The working group last call ends on December 12.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
> [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt
>
> Thank you,
> Netmod Chairs
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Dec 2017 12:30:46 +0100

Balazs,

the behaviour you assume is not defined in RFC 7950 and hence
everything is marked explicitely as deprecated. We had a discussion on
this, search the archives if you are interested.

I personally see an advantage with explicit deprecation marks since if
I look at an isolated definition of a leaf, it says 'deprecated' and
not 'current', i.e., I know the status of a leaf by looking at the
leaf and I do not have to search up the tree whether there is
something overwriting the status. Note that no status defined means
status current, it does not mean status inherited.

/js

On Fri, Dec 01, 2017 at 12:23:24PM +0100, Balazs Lengyel wrote:
> Hello,
> 
> container interfaces-state  is deprecated. I assume that if a container or
> list is deprecated, then all its contents are also deprecated.  Is there a
> need to mark all leafs deprecated too?
> 
> regards Balazs
> 
> 

-- 
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: Balazs Lengyel <[email-masked]>
Date: Fri, 1 Dec 2017 12:37:06 +0100

Hello,

https://tools.ietf.org/html/rfc7950#section-7.21.2

o "deprecated" indicates an obsolete definition, but it permits
new/continued implementation in order to foster interoperability
with older/existing implementations.

This means that a node that is deprecated MAY
or MAY NOT be implemented.

YANG is considered an interface contract,  however "maybe
implemented" is unusable in a contract.

YANG already has a statement defined for indicating such optional
support: the feature statement.

Deprecated works as if there would be an if-feature statement on
each deprecated schema node

where the server does not advertise whether the feature is
supported of not. Why is it not advertised?

I would like to propose to use a feature here. This
would allow the client to understand if the container
interfaces-state is implemented or not.

module ietf-interfaces {
feature pre-nmda-support {
description "The feature indicates that
schema parts representing state information
are deprecated but are still implemented."
}

container interfaces {...}

container interfaces-state {
if-feature pre-nmda-support ;
status deprecated;
...
}
}

regards Balazs

All,

Thank you,
Netmod Chairs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Dec 2017 09:49:33 -0800

On Fri, Dec 1, 2017 at 3:37 AM, Balazs Lengyel <[email-masked]>
wrote:

> This means that a node that is deprecated MAY or MAY NOT be implemented.
> YANG is considered an interface contract,  however "maybe implemented" is
> unusable in a contract.
>

I agree that the status-stmt is mostly worthless the way it is defined in
RFC 7950.
The good news is that the text in RFC 2578 (which it is based on) is much
worse,
so we are getting better over time.

The word "permits", rather than "requires" indicates this is a MAY, not
even a SHOULD,
and certain not a MUST.

YANG already has a statement defined for indicating such optional support:
> the feature statement.
> Deprecated works as if there would be an if-feature statement on each
> deprecated schema node
> where the server does not advertise whether the feature is supported of
> not. Why is it not advertised?
>
> I would like to propose to use a feature here. This would allow the
> client to understand if the container interfaces-state is implemented or
> not.
>
> module ietf-interfaces {

This proposal seems useful. Maybe it could be generalized,
because the issue is status=deprecated, not NMDA.

>  regards Balazs

Andy

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

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 1 Dec 2017 14:41:07 -0800

Hi -

On 12/1/2017 3:37 AM, Balazs Lengyel wrote:
> YANG is considered an interface contract,  however "maybe implemented" 
> is unusable in a contract.

 From a client perspective, access control can have similar consequences.
A contract only outlines some of the kinds of things that
might possibly exist.  It doesn't tell you what's actually there or
whether you're allowed to do anything with them.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Dec 2017 16:23:33 -0800

On Fri, Dec 1, 2017 at 2:41 PM, Randy Presuhn <
[email-masked]> wrote:

>From a vendor perspective the issue Balazs is raising can affect support
contracts.
YANG status-stmt does change the contract for the specific object.
The status deprecated is essentially the same as obsolete. There is
no useful warning that an object can be removed from a server in the future.
The warning says "the object can be removed right now".

The deprecated status could have been defined to be the same as current,
except
the object will likely go away in the future.  Existing implementations MUST
support the object until it is obsolete.  New implementations SHOULD NOT
include the object.

For YANG linkage issues, new revisions SHOULD NOT add new statements that
use
deprecated objects. Existing linkage would be reliable to use until the
referenced definition is obsolete.

Randy
Andy

---

From: Qin Wu <[email-masked]>
Date: Mon, 4 Dec 2017 02:46:14 +0000

I have read this draft and believe it is ready for publication.
One question I have is why rfc7223bis not reference NMDA guidelines since it get in line with NMDA guideline, or NMDA guideline has been 
merged into rfc6087bis?
Should this draft reference rfc6087bis?

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2017年11月29日 3:29
收件人: [email-masked]
抄送: [email-masked]
主题: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

All,

This starts a two-week working group last call on draft-ietf-netmod-rfc7223bis-00.

Please recall that this update's intention is to modify the YANG module to be in line with the NMDA guidelines [1].  Reviewing the diff between the two drafts [2] should reveal just this.

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Netmod Chairs

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 4 Dec 2017 10:21:35 +0100

> whether you're allowed to do anything with them.
BALAZS : Disagree. From a client point of view it may look like the 
same, but from an operator (company) point of view it is different. If I 
am an operator like Vodafone or ATnT, if the restriction is based on 
access control, I can change my procedures to permit the usage. However 
if something is removed based on deprecated, I have no solution.

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 4 Dec 2017 10:22:43 +0100

On 2017-12-01 18:49, Andy Bierman
wrote:

On Fri, Dec 1, 2017 at 3:37 AM,
Balazs Lengyel <[email-masked]>
wrote:

Hello,

This means
that a node that is deprecated MAY or MAY NOT be
implemented.

YANG is considered an interface contract,  however
"maybe implemented" is unusable in a contract.

I agree that the status-stmt is mostly worthless the
way it is defined in RFC 7950.

The good news is that the text in RFC 2578 (which it is
based on) is much worse,

The word "permits", rather than "requires" indicates
this is a MAY, not even a SHOULD,

and certain not a MUST.

YANG
already has a statement defined for indicating such
optional support: the feature statement.

Deprecated works as if there would be an if-feature
statement on each deprecated schema node

where the server does not advertise whether the
feature is supported of not. Why is it not advertised?

I would like to propose to use a feature here. This would allow the client to
understand if the container interfaces-state is
implemented or not.

module ietf-interfaces {

This proposal seems useful. Maybe it could be
generalized,

Andy

BALAZS: Yes, IMHO it should be generalized.

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Dec 2017 15:13:46 +0100 (CET)

Alex Campbell <[email-masked]> wrote:
> On page 37, "duplex" is mistyped as "duplexx".

Thanks, now fixed.

/martin

> 
> Other than this minor error, I believe this draft is ready for publication.
> 
> ________________________________________
> From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
> Sent: Wednesday, 29 November 2017 8:29 a.m.
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00
> 
> All,
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Dec 2017 15:44:48 +0100 (CET)

Hi,

I don't think that our documents reference the guidelines document,
and I don't think they need to.  RFC 7223 does not reference RFC
6087, for example.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 5 Dec 2017 21:06:42 +0000

Hi Martin,

Several comments on the YANG model within rfc7223bis.

list interface {
        key "name";
        description
          "The list of interfaces on the device.  The status of an interface is available in this list in the
           operational state...

A few questions on this.
(a) The description of the list defines behaviors of various list nodes which might or might not exist in different NMDA datastores.  It also suggests when certain elements should be populated in various datastores.  Is the precedence being set that datastore specific behaviors may be placed into descriptions?  Is this type of documentation guidance something which explored in draft-dsdt-nmda-guidelines?   
(b) Does status mean 'admin-status', 'oper-status' or both?  (I think 'oper-status'.)
(c) should quotes be used around status?

leaf name {,   leaf type { ....
There are NETCONF specific behaviors in the definition of these two leaves.   It would be great to have this transport agnostic.  I realize that such a transport segmentation dissociates transport error handling from the nodes being handled.

leaf admin-status {...
incorrectly marked  as config false;

Thanks,
Eric

> > Please recall that this update's intention is to modify the YANG module to
> be in line with the NMDA guidelines [1].  Reviewing the diff between the
> two drafts [2] should reveal just this.
> >
> > [2]
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.tx
> > t
> >
> > Thank you,
> > Netmod Chairs
> >
> >

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 6 Dec 2017 13:49:01 +0100

> incorrectly marked  as config false;
I think config false; is correct. The 'admin-status' leaf is a pre-NMDA 
workaround for IF-MIB implementations that coexist with the 
ietf-interfaces implementation e.g. reflect the value of ifAdminStatus 
independently configurable of the /interfaces/interface/enabled value. 
This is described in the description statement of 
/interfaces/interface/enabled.

This potentially could also be accomplished by using NMDA origin meta 
notation in operational showing /interfaces/interface/enabled is 
overwritten by origin that is not 'intended' e.g. or:origin=or:system or 
maybe custom origin or:origin=or-snmp:snmp?

IMO 'admin-status' is a too broad name for something that is only if-mib 
relevant. This is an example of something that can be solved with NMDA 
in a more general way without clogging the model with additional leaf 
but for backward compatibility and to avoid unnecessary confusion should 
be kept the way it is in draft-ietf-netmod-rfc7223bis-00.

Vladimir

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Dec 2017 09:00:26 +0100 (CET)

Hi Eric,

"Eric Voit (evoit)" <[email-masked]> wrote:
> (a) The description of the list defines behaviors of various list
> nodes which might or might not exist in different NMDA datastores.  It
> also suggests when certain elements should be populated in various
> datastores.  Is the precedence being set that datastore specific
> behaviors may be placed into descriptions?

I don't know; I guess it depends on what people think about this
style.  I think that when the mapping between config and operational
state is not 1-1 and obvious, it needs to be somehow explained in the
description - just like the old descriptions did, except that where
the old descriptions refered to different *nodes*, we now refer to
different *intantiations* of the same node.

> Is this type of
> documentation guidance something which explored in
> draft-dsdt-nmda-guidelines?

I don't think so.

> (b) Does status mean 'admin-status', 'oper-status' or both?  (I think

No, it is intended to mean the status of the interface in general.

> (c) should quotes be used around status?

No, since it's not the name of a specific node.

> There are NETCONF specific behaviors in the definition of these two
> leaves.  It would be great to have this transport agnostic.

One thing to note is that this also should apply to a RESTCONF
server.  But adding that doesn't really address your point :)
However, I don't know what the correct way of handling this would be.
We could be less specific and just write that the server MUST return
an "invalid-value" error, but less specific might also be more
confusing.

> I realize
> that such a transport segmentation dissociates transport error
> handling from the nodes being handled.
> 
> leaf admin-status {...

See the reply from Vladimir; this is corrcect.

/martin

> > > Positive comments, e.g., "I've reviewed this document and believe it
> > > is
> > ready for publication", are welcome!

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Dec 2017 07:04:04 +0000

All, 

  This last call is now closed.  Since the comments
  were minor, this last call is considered successful.

Authors,

  Please address any/all comments received during 
  the LC.  Once you've published the version that 
  you believe addresses all comments/pending changes,
  I'll perform the Shepherd review.

Special thanks to Vladimir the extensive analysis!

Kent // shepherd

===== original message =====

All,

Thank you,
Netmod Chairs