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

[Loa Andersson <[e-mail]>]

Zafar,

Thanks for addressing this. However one thing remains. The text is now:

"There MAY be additional segments preceding the END.OP/ END.OTP SID."

I don't think there is a need for requirement language in that sentence,
I read it as straightforward English:

"There may be additional segments preceding the END.OP/ END.OTP SID."

Would do very well.

Can you explain the need for requirement language?

/Loa



On 22/01/2020 01:55, Zafar Ali (zali) wrote:
> Hi Brian,
> 
> Many thanks for your comments. Much appreciated.
> 
> The working copy of the new version in the repository addresses your/ 
> Loa’s comment highlighted in your email.
> 
> https://github.com/ietf-6man/srv6-oam
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *spring <[e-mail]> on behalf of Brian E Carpenter 
> <[e-mail]>
> *Organization: *University of Auckland
> *Date: *Monday, January 20, 2020 at 2:57 PM
> *To: *Loa Andersson <[e-mail]>, Ole Troan <[e-mail]>, 6man 
> WG <[e-mail]>, SPRING WG <[e-mail]>
> *Cc: *6man Chairs <[e-mail]>
> *Subject: *Re: [spring] 6man w.g. last call for 
> <draft-ietf-6man-spring-srv6-oam>
> 
> To be clear about one of the points in the review, MAY NOT is not 
> allowed by RFC2119 because it is totally ambiguous in English (since it 
> can mean either "must not" or "might not"). In any case the phrase "MAY 
> or MAY NOT" is not of any normative value. It presumably simply means 
> "MAY" in all cases in this draft.
> 
> Regards
> 
>     Brian
> 
> On 20-Jan-20 20:54, Loa Andersson 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] <mailto:[e-mail]>
> 
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>         --------------------------------------------------------------------
> 
>     --------------------------------------------------------------------
> 
>     IETF IPv6 working group mailing list
> 
>     [e-mail] <mailto:[e-mail]>
> 
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>     --------------------------------------------------------------------
> 
> _______________________________________________
> 
> spring mailing list
> 
> [e-mail] <mailto:[e-mail]>
> 
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]