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

From: Loa Andersson <[email-masked]>
Date: Mon, 20 Jan 2020 15:54:41 +0800

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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Bob Hinden <[email-masked]>
Date: Mon, 20 Jan 2020 03:12:41 -0800

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 <[email-masked]> wrote:
> 
> WG,
> 
>  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
>  ** There are 3 instances of too long lines in the document, the longest one
>  == 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
> 
>     defined in RFC 2119.  If it is intended as a requirements expression, it
>  == 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
>     segment-list of the SRH immediately preceding the target SID. There MAY
>  == 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
>     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
>     (See RFCs 3967 and 4897 for information about using normative references
>  == Missing Reference: 'RFC 8403' is mentioned on line 660, but not defined
> 
>     Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments (--).
> 
>     Run idnits with the --verbose option for more detailed information about
>     the items above.
> 
> <draft-ietf-6man-spring-srv6-oam-03.txt>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 20 Jan 2020 19:31:11 +0000

Hi Loa,

Many thanks for your detailed review – greatly appreciated.

I agree with Bob.
I looked at the text file. The word document will make the comments, clearer. Please share.

Looking forward to work with you to close on your comments.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Monday, January 20, 2020 at 6:13 AM
To: Loa Andersson <[email-masked]>
Cc: IPv6 List <[email-masked]>, Ole Trøan <[email-masked]>, Bob Hinden <[email-masked]>, SPRING WG <[email-masked]>, 6man Chairs <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Loa,

Bob

On Jan 19, 2020, at 11:54 PM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
WG,
[email-masked]<mailto:[email-masked]>
Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jan 2020 08:56:09 +1300

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

---

From: Loa Andersson <[email-masked]>
Date: Tue, 21 Jan 2020 10:20:57 +0800

Bob,

Here is the docx-file, it is not exactly the same version as I used to
create the txt-file, since I continued to look at the figure for the
reference topology, and in that process I also corrected a spelling
erros and cleared up the text for some comments.

The only real change is that I have added an alternative to the figure
(note: no problems with the topology itself) for the reference topology
at the end of the docx file.

/Loa

--

---

From: Bob Hinden <[email-masked]>
Date: Mon, 20 Jan 2020 23:16:10 -0800

Loa,

Thanks, that is very helpful.

Bob

> On Jan 20, 2020, at 6:20 PM, Loa Andersson <[email-masked]> wrote:
> 
> Bob,
> 
> 
> <draft-ietf-6man-spring-srv6-oam-03-A.docx>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 21 Jan 2020 17:55:01 +0000

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 <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Organization: University of Auckland
Date: Monday, January 20, 2020 at 2:57 PM
To: Loa Andersson <[email-masked]>, Ole Troan <[email-masked]>, 6man WG <[email-masked]>, SPRING WG <[email-masked]>
Cc: 6man Chairs <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Regards
   Brian

as a Proposed Standard.

Thanks,

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Jan 2020 10:58:27 +0800

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:
> *From: *spring <[email-masked]> on behalf of Brian E Carpenter 
> <[email-masked]>
> *Organization: *University of Auckland
> *Date: *Monday, January 20, 2020 at 2:57 PM
> *To: *Loa Andersson <[email-masked]>, Ole Troan <[email-masked]>, 6man 
> WG <[email-masked]>, SPRING WG <[email-masked]>
> *Cc: *6man Chairs <[email-masked]>
> *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
> 
>              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)
> 
>         Substantive comments and statements of support for publishing
>         this document should be directed to the mailing list.
> 
>         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,
> 
>         [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> 

--

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 22 Jan 2020 05:15:00 +0000

Hi Loa,

Many thanks for your follow-up.
Based on your feedback, we have updated the version in the GitHub.

Thanks

Regards … Zafar

From: Loa Andersson <[email-masked]>
Date: Tuesday, January 21, 2020 at 9:59 PM
To: "Zafar Ali (zali)" <[email-masked]>, Brian E Carpenter <[email-masked]>, Ole Troan <[email-masked]>, 6man WG <[email-masked]>, SPRING WG <[email-masked]>
Cc: 6man Chairs <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Zafar,

Would do very well.

/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 <[email-masked]<mailto:[email-masked]>> on behalf of Brian E Carpenter
<[email-masked]<mailto:[email-masked]>>
*Organization: *University of Auckland
*Date: *Monday, January 20, 2020 at 2:57 PM
*To: *Loa Andersson <[email-masked]<mailto:[email-masked]>>, Ole Troan <[email-masked]<mailto:[email-masked]>>, 6man
WG <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>
*Cc: *6man Chairs <[email-masked]<mailto:[email-masked]>>
*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
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
         --------------------------------------------------------------------
     --------------------------------------------------------------------
     IETF IPv6 working group mailing list
     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
     --------------------------------------------------------------------
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Jan 2020 18:02:47 +0800

Zafar,

Tnx - 1 down 36 to go!

Actually a bit more with the NITs output. Can you take a look at the 
long lines next, it should be easy edits.

The first two long lines are in this paragraph:

248	     S01.1. IF SRH.Flags.O-flag is set and local configuration permits
249	            O-flag processing THEN
250	            a. Make a copy of the packet.
251	            b. Send the copied packet, along with a timestamp
252	               to the OAM process.      ;; Ref1
253	     Ref1: An implementation SHOULD copy and record the timestamp as 
soon as
254	     possible during packet processing. Timestamp is not carried in 
the packet
255	     forwarded to the next hop.

Line 253 has four characters "n as" outside the allowed 72 characters
Line 254 has the word "packet" outside the allowed 72 characters

This is inside the figure and I think that you can left shift the
enire figure, otherwise I don't see a problem with introducing line
breaks.

In figure 4:

639	     > traceroute srv6 B:4:C52 via segment-list B:2:C31

641	     Tracing the route to SID function B:4:C52
642	      1  2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec
643	         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2)
644	      2  2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec
645	         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)
646	      3  2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec
647	         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)

649	        Figure 4 A sample output for hop-by-hop traceroute to a SID 
function

Line 649 has "tion" of "SID function" (fig numbring) outside the allowed
72 characters, again should be easy to left shif or introduce line
breaks.

The reason I want to address this first is that it is easy, but also
a show stopper.

And last, thugh I hate to add late comments - abbreviations, I have not
gone through the entire document to look for unexpanded abbreviations,
but there is at least one "NPU". Which I read as Network Processing Unit,
what confuses me is that it is not in the RFC Editors abbreviation list
at all. I think there is an action point for the wg chairs to have it
introduced, and for the authros to expand, as well as going through the
document an d make sure that everthing that should be expanded is.

/Loa

On 22/01/2020 13:15, Zafar Ali (zali) wrote:
> *From: *Loa Andersson <[email-masked]>
> *Date: *Tuesday, January 21, 2020 at 9:59 PM
> *To: *"Zafar Ali (zali)" <[email-masked]>, Brian E Carpenter 
> <[email-masked]>, Ole Troan <[email-masked]>, 6man WG 
> <[email-masked]>, SPRING WG <[email-masked]>
>     *From: *spring <[email-masked]
>     <mailto:[email-masked]>> on behalf of Brian E Carpenter
> 
>     <[email-masked] <mailto:[email-masked]>>
> 
>     *To: *Loa Andersson <[email-masked] <mailto:[email-masked]>>, Ole Troan
>     <[email-masked] <mailto:[email-masked]>>, 6man
> 
>     WG <[email-masked] <mailto:[email-masked]>>, SPRING WG
>     <[email-masked] <mailto:[email-masked]>>
> 
>     *Cc: *6man Chairs <[email-masked] <mailto:[email-masked]>>
> 
>     https://www.ietf.org/id-info/checklist :
> 
>          
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>               Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
> 
>              
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>           Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
> 
>          
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
> Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
> 
> Senior MPLS Expert
> 
> [email-masked]

--

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 23 Jan 2020 23:46:37 +0000

Loa,

Many thanks.
The comments in your email has been addressed in latest version in the GitHub.
We are working to address the rest of your comments.

Thanks

Regards … Zafar

Date: Wednesday, January 22, 2020 at 5:03 AM

Zafar,

Tnx - 1 down 36 to go!

In figure 4:

/Loa

On 22/01/2020 13:15, Zafar Ali (zali) wrote:
Hi Loa,
Many thanks for your follow-up.
Based on your feedback, we have updated the version in the GitHub.
Thanks
Regards … Zafar
*From: *Loa Andersson <[email-masked]<mailto:[email-masked]>>
*Date: *Tuesday, January 21, 2020 at 9:59 PM
*To: *"Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Brian E Carpenter
<[email-masked]<mailto:[email-masked]>>, Ole Troan <[email-masked]<mailto:[email-masked]>>, 6man WG
<[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>
*Cc: *6man Chairs <[email-masked]<mailto:[email-masked]>>
*Subject: *Re: [spring] 6man w.g. last call for
<draft-ietf-6man-spring-srv6-oam>
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 <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]><mailto:[email-masked]%3e>> on behalf of Brian E Carpenter
     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>
     *Organization: *University of Auckland
     *Date: *Monday, January 20, 2020 at 2:57 PM
     *To: *Loa Andersson <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>, Ole Troan
     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>, 6man
     WG <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>, SPRING WG
     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>
     *Cc: *6man Chairs <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>
     *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):

     ----------------------------------------------------------------------------
                ** 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
                -- 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: 'RFC 8403' is mentioned on line
     660, but not
                    Author   : Z. Ali, C. Filsfils, S. Matsushima, D.
     Voyer, M.
               Editorial suggestions can be sent to the author. This last
     call

     --------------------------------------------------------------------
               IETF IPv6 working group mailing list
     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
               Administrative Requests:
     https://www.ietf.org/mailman/listinfo/ipv6

     --------------------------------------------------------------------
           IETF IPv6 working group mailing list
     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
           Administrative Requests:
     https://www.ietf.org/mailman/listinfo/ipv6

     --------------------------------------------------------------------
     _______________________________________________
     spring mailing list
     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
     https://www.ietf.org/mailman/listinfo/spring
--
Loa Andersson                        email: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

--