Subject: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 17 May 2016 20:59:20 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6020bis-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Meta comment:

Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in
the draft

Section 4.2.4:

s/A reference a data tree node/A reference to a data tree node

Section 9.4.7:

It is not clear why the following refinement is illegal. Can you
clarify?

     type my-base-str-type {
       // illegal length refinement
       length "1..999";
     }

IANA considerations:

Not sure what is the correct method for doing this in -bis documents, but
I would have expected a note that instructs IANA to switch references to
RFC6020 in IANA registries over to this one.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 May 2016 08:58:43 +0200

> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/

I guess this is because there are a couple of RFCs that depend on
RFC6020 and so we can't retire RFC6020 right now.

>        // illegal length refinement

Because my-base-str-type is restricted to length "1..255" and you
can't enlarge the length restriction in a refinement.

> RFC6020 in IANA registries over to this one.

This is what the WG originally thought but then we got advice that the
original IANA allocation should stay in force...

/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: Wed, 18 May 2016 14:49:43 +0200

> original IANA allocation should stay in force...

Right, and this is also, I believe, a specific reason why 6020 cannot be
obsoleted.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Benoit Claise <[email-masked]>
Date: Wed, 18 May 2016 16:23:04 +0200

> RFC6020 and so we can't retire RFC6020 right now.
Right.
This is also covered in the writeup.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

   No. YANG 1.0 [RFC6020] is not expected to change its status since
   there are data models on the standards-track that conform to YANG
   1.0. YANG 1.0 may be considered for retirement once all data models
   have naturally been updated to a future version of YANG.

Regards, Benoit

> original IANA allocation should stay in force...
Yes, we checked that with Michelle Cotton.

Regards, Benoit

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 May 2016 13:51:55 +0000

Thanks Juergen and Lada for the explanation. I now understand the motivations
not to obsolete.

Regards
Suresh