Subject: [netmod] 6087bis shepherd writeup issues

From: Kent Watsen <[email-masked]>
Date: Sat, 22 Oct 2016 13:01:42 +0000

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)

---

From: Andy Bierman <[email-masked]>
Date: Sat, 22 Oct 2016 11:56:56 -0700

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-masked]> 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:
>
>
>
>
>
> 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?
>
>
>
> 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.]
>
>
>
> 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
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>