Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

["Carlos Pignataro (cpignata)" <[e-mail]>]

Brian,

Thank you for your GenART review!

I will let the authors comment on and propose edits for the “units” minor issue and the nits. 

However, please find one comment inline.

> On Oct 14, 2017, at 12:39 AM, Brian Carpenter <[e-mail]> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART *Last Call* review of draft-ietf-lime-yang-connectionless-oam-methods-09
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-lime-yang-connectionless-oam-methods-09.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-10-14
> IETF LC End Date: 2017-10-25
> IESG Telechat date: 2017-10-26
> 
> Summary: Ready with issues
> --------
> 
> Comment:
> --------
> 
> The shepherd says:
> 
>> This includes at least two different implementations of
>> the model, as well as product and demos at Bits-n-Bytes.
> 
> Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving
> Awareness of Running Code: The Implementation Status Section"?
> 

Yes!!!

Although a section in an Internet-Draft is not the most convenient way of tracking running code, it is better than none. At least, it self-contains spec and code status within a single document. As an editor I tend to add it as much as it makes sense.

As shepherd/chair for this document, unfortunately, at this stage it is too late for these document to play catch-up with another section, given that:

   Since this information is necessarily time dependent, it is
   inappropriate for inclusion in a published RFC.  The authors should
   include a note to the RFC Editor requesting that the section be
   removed before publication.

That said, I would strongly encourage you to discuss this topic and find ways to make more intentional in-the-workflow use of the “”Implementation Status”. This is a good comment but a wrong target.

Your comment starts with “Shouldn't WGs”, so this is a comment that ought to be directed to the Wg-chairs mailer, the IESG, early reviewers and Directoragtes, and other more relevant vehicles.

Thanks,

— Carlos.

> Minor Issues:
> -------------
> 
> In the following:
> 
>         |  +--ro min-delay-value?         uint32
>         |  +--ro max-delay-value?         uint32
>         |  +--ro average-delay-value?     uint32
>         +--ro session-jitter-statistics
>         |  +--ro time-resolution-value?   identityref
>         |  +--ro min-jitter-value?        uint32
>         |  +--ro max-jitter-value?        uint32
>         |  +--ro average-jitter-value?    uint32
> 
> what are the units for the delay-value and jitter-value
> elements, and what definition of 'jitter' is intended?
> 
> 
>  identity protocol-id-internet {
>    base protocol-id;
>    description
>      "Internet Protocols.";
>  }
> 
> It isn't clear what "Internet Protocols" means. It seems totally non-specific.
> 
> Nits:
> -----
> 
>  identity protocol-id-propreitary {
>    base protocol-id;
>    description
>      "Propreitary protocol (eg.,IP SLA).";
> 
> s/propreitary/proprietary/
> s/Propreitary/Proprietary/
> 
>