Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

[Bob Hinden <[e-mail]>]

Loa,

Thanks for doing the review.  I think it may be worthwhile to also send out the .docx file in addition to the text version.

Bob


> On Jan 19, 2020, at 11:54 PM, Loa Andersson <[e-mail]> wrote:
> 
> WG,
> 
> I have reviewed the entire document.
> 
> First, I'm not an IPv6 expert.
> 
> As far as I can see the sued on
> 
> I have not used github, I had a couple of attempts to learn the tools,
> but so far I have failed.
> 
> I have instead done what I use to do, use the review tool with Word.
> 
> Since I sometimes have a pushback on the docx-format I save the result
> as a .txt-file. Drawback is that all comment show up as refrences to a
> list at the end of the document. But you can't get everything.
> 
> 
> /Loa
> 
> PS gives this output for this draft; it is quite a lot and in itself are
> so much that it is worth sending it bck to the authors and asking them
> to fix it. Was the noits tool checked at all before starting the wglc?
> 
> idnits 2.16.02
> 
> /tmp/draft-ietf-6man-spring-srv6-oam-03.txt:
> 
>  Checking boilerplate required by RFC 5378 and the IETF Trust (see
>  https://trustee.ietf.org/license-info):
> ----------------------------------------------------------------------------
> 
>     No issues found here.
> 
>  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
> ----------------------------------------------------------------------------
> 
>     No issues found here.
> 
>  Checking nits according to https://www.ietf.org/id-info/checklist :
> ----------------------------------------------------------------------------
> 
>  ** There are 3 instances of too long lines in the document, the longest one
>     being 6 characters in excess of 72.
> 
>  == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses
>     in the document.  If these are example addresses, they should be changed.
> 
> 
>  Miscellaneous warnings:
> ----------------------------------------------------------------------------
> 
>  == The copyright year in the IETF Trust and authors Copyright Line does not
>     match the current year
> 
>  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
>     defined in RFC 2119.  If it is intended as a requirements expression, it
>     should be rewritten using one of the combinations defined in RFC 2119;
>     otherwise it should not be all-uppercase.
> 
>  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
>     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
>     NOT' instead (if that is what you mean).
> 
>     Found 'MAY NOT' in this paragraph:
> 
>     To perform ICMPv6 ping to a target SID an echo request message is
>     generated by the initiator with the END.OP or END.OTP SID in the
>     segment-list of the SRH immediately preceding the target SID. There MAY
>     or MAY NOT be additional segments preceding the END.OP/ END.OTP SID.
> 
>  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
>     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
>     NOT' instead (if that is what you mean).
> 
>     Found 'MAY NOT' in this paragraph:
> 
>     To traceroute a target SID a probe message is generated by the
>     initiator with the END.OP or END.OTP SID in the segment-list of the SRH
>     immediately preceding the target SID.  There MAY or MAY NOT be additional
>     segments preceding the END.OP/ END.OTP SID.
> 
>  -- The document date (December 18, 2019) is 32 days in the past.  Is this
>     intentional?
> 
> 
>  Checking references for intended status: Proposed Standard
> ----------------------------------------------------------------------------
> 
>     (See RFCs 3967 and 4897 for information about using normative references
>     to lower-maturity documents in RFCs)
> 
>  == Missing Reference: 'SL' is mentioned on line 190, but not defined
> 
>  -- Looks like a reference, but probably isn't: '2' on line 191
> 
>  -- Looks like a reference, but probably isn't: '1' on line 191
> 
>  -- Looks like a reference, but probably isn't: '0' on line 192
> 
>  == Missing Reference: 'RFC7011' is mentioned on line 230, but not defined
> 
>  == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is mentioned on line
>     241, but not defined
> 
>  == Missing Reference: 'RFC792' is mentioned on line 701, but not defined
> 
>  == Missing Reference: 'RFC 8403' is mentioned on line 660, but not defined
> 
>  == Unused Reference: 'RFC0792' is defined on line 823, but no explicit
>     reference was found in the text
> 
>  == Unused Reference: 'RFC8403' is defined on line 843, but no explicit
>     reference was found in the text
> 
>  == Outdated reference: A later version (-08) exists of
>     draft-ietf-spring-srv6-network-programming-06
> 
> 
>     Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments (--).
> 
>     Run idnits with the --verbose option for more detailed information about
>     the items above.
> 
> On 05/12/2019 04:53, Ole Troan wrote:
>> Hello,
>>   As agreed in the working group session in Singapore, this message starts a new two week 6MAN Working Group Last Call on advancing:
>>   Title    : Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
>>   Author   : Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen
>>   Filename : draft-ietf-6man-spring-srv6-oam-02
>>   Pages    : 23
>>   Date     : 2019-11-20
>>                               https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
>> as a Proposed Standard.
>> Substantive comments and statements of support for publishing this document should be directed to the mailing list.
>> Editorial suggestions can be sent to the author. This last call will end on the 18th of December 2019.
>> To improve document quality and ensure that bugs are caught as early as possible, we would require at least
>> two reviewers to do a complete review of the document.  Please let the chairs know if you are willing to be a reviewer.
>> The last call will be forwarded to the spring working group, with discussion directed to the ipv6 list.
>> Thanks,
>> Bob & Ole, 6man co-chairs
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: [phone]
> <draft-ietf-6man-spring-srv6-oam-03.txt>