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:
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 <l...@pi.nu>
*Date: *Tuesday, January 21, 2020 at 9:59 PM
*To: *"Zafar Ali (zali)" <z...@cisco.com>, Brian E Carpenter
<brian.e.carpen...@gmail.com>, Ole Troan <otr...@employees.org>, 6man WG
<i...@ietf.org>, SPRING WG <spring@ietf.org>
*Cc: *6man Chairs <6man-cha...@ietf.org>
*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 <spring-boun...@ietf.org
<mailto:spring-boun...@ietf.org>> on behalf of Brian E Carpenter
<brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>>
*Organization: *University of Auckland
*Date: *Monday, January 20, 2020 at 2:57 PM
*To: *Loa Andersson <l...@pi.nu <mailto:l...@pi.nu>>, Ole Troan
<otr...@employees.org <mailto:otr...@employees.org>>, 6man
WG <i...@ietf.org <mailto:i...@ietf.org>>, SPRING WG
<spring@ietf.org <mailto:spring@ietf.org>>
*Cc: *6man Chairs <6man-cha...@ietf.org <mailto:6man-cha...@ietf.org>>
*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
i...@ietf.org <mailto:i...@ietf.org> <mailto:i...@ietf.org>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org <mailto:i...@ietf.org> <mailto:i...@ietf.org>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
--
Loa Andersson email: l...@pi.nu <mailto:l...@pi.nu>
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--
Loa Andersson email: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
