Andy, all,
In reviewing the draft for Shepherd writeup, I found the following issues that
I think need to be addressed before the document can be sent to Benoit for AD
review:
1. Idnits found the following:
== Missing Reference: 'RFC6242' is mentioned on line 2233, but not defined
== Outdated reference: draft-ietf-netmod-rfc6020bis has been published as RFC
7950
** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322)
** Obsolete normative reference: RFC 5741 (Obsoleted by RFC 7841)
2. the intended status is “Standards Track”, but RFC 6087 is “Informational”.
Please change to the bis to be Information as well.
3. The Abstract and Introduction both call out NETCONF, but say nothing about
RESTCONF. Should they at least refer to both equally?
4. Currently there is a Normative reference to NETCONF, but I believe that it
should it be Informative, right?
5. RESTCONF is mentioned in the draft, but there is no reference for RESTCONF.
There should be an Informative reference for RESTCONF as well.
6. Section 4.1 regards “Module Copyright”, but after the first paragraph it
starts talking about "<CODE BEGINS>" and "<CODE ENDS>". I’m thinking this must
be a mistake, that the CODE BEGIN/END stuff was meant to be in another section
(a new 4.2?). [BTW, that an issue like this got through suggests to me that
folks haven’t been reading this document, I’ll discuss with my co-chair if we
need to do Last Call again.]
7. I think that 6087bis needs to obsolete RFC 6087, but it’s not labeled as
such yet.
8. Related to #7 above, the IANA Considerations section registers a URI in the
IETF XML registry, but this was done in RFC 6087, so it can’t be done again,
right? I suggest updating the IANA Considerations section to say that 1) this
document continues to empower registry entry’s existence (given that the
document obsoletes RFC 6087) and 2) IANA should update their records to point
to this RFC for the one that empowers the registry entry. Make sense?
9. Regarding section 5.23, per extensive discussion with the AD, co-chair, and
the datastore design team, we believe that Section 5.23 can be improved to more
precisely describe the guidance. As such, we recommend something along the
lines of the following two changes be made:
OLD
Placing operational data within
the configuration subtree is appropriate if the operational values
can only exist if the configuration exists.
NEW
Placing operational data within
the configuration subtree is appropriate if the operational values
can only exist if the configuration exists. Placing operational data
outside the configuration subtree is appropriate if the operational
values can exist without corresponding configuration (e.g., system
generated interfaces).
OLD
Sometimes the configured value represents some sort of procedure to
be followed, in which the system will select an actual value, based
on protocol negotiation.
NEW
Sometimes the configured value represents some sort of procedure to
be followed, in which the system will select an actual value, based
on protocol negotiation. In this case it is RECOMMENDED to have a
separate config false value to represented the resulting state. For
instance:
Thanks,
Kent (as document shepherd)
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
