Hi, I will create an updated draft before the I-D cutoff
Andy On Sat, Oct 22, 2016 at 6:01 AM, Kent Watsen <[email protected]> wrote: > > > 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 > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
