Re: [netmod] 6087bis shepherd writeup issues

[Kent Watsen <[e-mail]>]

Hi Andy,

Thanks for posting -09.

Running it through Idnits again, I noticed the following:

  -- The draft header indicates that this document obsoletes RFC6087,
     but the abstract doesn't seem to mention this, which it should.

  == Missing Reference: 'RFCXXXX' is mentioned on line 378, but not defined

  == Outdated reference: A later version (-18) exists of
     draft-ietf-netconf-restconf-17

For the first item, it only mentions the abstract, but the Shepherd writeup refers
to both abstract and introduction, so please consider updating both.

For the second item, I believe that this is not an error, but it took me a while
to realize this.  I believe this sentence in Section 4.3 intention is for the other
drafts to point to Section 3 in this draft.  If so, then I recommend the sentence
ending “...is defined in Section 3 in [RFCXXXX]”.

Additionally, in looking at the IANA Considerations section, I think the RFC Ed.
note is wrong.  You don’t want to update [RFC6087] to [RFCXXXX] in this case,
right?

For the sake of efficiency, I’ll forward the current draft to the AD now, but
please make these updates to your local copy, with an expectation that
there might be more updates needed per the AD’s review.


Thanks,
Kent


From: Andy Bierman <[e-mail]>
Date: Saturday, October 22, 2016 at 2:56 PM
To: Kent Watsen <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [netmod] 6087bis shepherd writeup issues

Hi,

I will create an updated draft before the I-D cutoff


Andy


On Sat, Oct 22, 2016 at 6:01 AM, Kent Watsen <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod