On 5/18/2016 8:58 AM, Juergen Schoenwaelder wrote:
On Tue, May 17, 2016 at 08:59:20PM -0700, Suresh Krishnan wrote:
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
I guess this is because there are a couple of RFCs that depend on
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
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";
}
Because my-base-str-type is restricted to length "1..255" and you
can't enlarge the length restriction in a refinement.
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.
This is what the WG originally thought but then we got advice that the
original IANA allocation should stay in force...
Yes, we checked that with Michelle Cotton.
Regards, Benoit
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
