Subject: [netmod] upcoming adoptions

From: Kent Watsen <[email-masked]>
Date: Tue, 29 Aug 2017 23:46:41 +0000

Hey folks,

As discussed at the last meeting, we are heading to revising existing RFCs to align them with NMDA.  The first batch have been published as individual drafts:

1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

Please take a look (comments welcome!) and stay tuned for the related adoption calls.

Thanks,
Kent (and Lou)

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Aug 2017 12:28:23 +0200 (CEST)

Hi,

> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

I found some trivial errors in this draft:

  o  The revision for ietf-routing doesn't match the filename's date.

  o  The filename for ietf-ipv6-router-advertisements is wrong (last
     "s" is missing)

  o  All the old -state definitions are removed, rather than being
     marked as "deprecated".

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 30 Aug 2017 11:53:36 +0000

Hi Martin, 

>  o  All the old -state definitions are removed, rather than being

I’m glad you brought this up. We discussed this in the Routing YANG Design
Team and were planning to discuss it on a wide scale.

One of the advantages of the NMDA is that it makes the models easier to
read and consume. This is somewhat negated if we have to retain all these
data nodes in the associated modules and mark them as “deprecated”. What
is the consequence of not including them? They are available in the
previous version of the model if they are need for compatibility.

Thanks,
Acee

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Aug 2017 14:07:56 +0200 (CEST)

> previous version of the model if they are need for compatibility.

It is fairly common that instead of removing functions from a
published API, you mark them as deprecated for some time, and then,
later, remove them (*).

Note that since a server cannot implement two versions of a given
module, it has to decide which version to implement.  There might be
other modules that use / augment the -state tree; if the server
implements the latest version w/o the -state tree, it cannot at the
same time implement these augmenting modules.

(*) YANG inherits the deprecation model from SMIv2.  We actually have
three states: current -> deprecated -> obsolete.  And even when
something is obsolete, it is not removed.  I guess in SMIv2 this was
necessary b/c of OID assignments; maybe this could be revisited for
YANG.  But this would require an update to RFC 7950.

If we think that a module becomes cluttered with all the deprecated
definitions, we can actually move them all to a separate submodule.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Aug 2017 14:35:36 +0200

> YANG.  But this would require an update to RFC 7950.

The equivalent to the OID assignment is the name of a data node, I
think it should not be reused. It is bad for interoperability if /foo
suddenly means something entirely different.

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