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

["Zafar Ali (zali)" <[e-mail]>]

Hi Zhenqiang,

Many thanks for your comments.
We have been maintaining the latest version of the draft in the Github to address all comments.
However, we just posted revision 3.

Add editorial comments has been fixed.
For non-editorial comments, please see in-line.

Thanks

Regards … Zafar

From: spring <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Friday, December 6, 2019 at 3:14 AM
To: Ole Troan <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: 6man Chairs <[e-mail]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hello Ole and all,

I re-read this version again with the following comments for the WGLC.

1. Section 4.2.2.2, the penultimate bullet.
The sentence "The traceroute process at node N4 checks if its local SID (B:2:C31) is locally programmed" should be "The traceroute process at node N4 checks if its local SID (B:4:C52) is locally programmed".

2. Requirements Language
[RFC8174] should be added as a nomative reference.

3. Section 3.5 SRH TLV
This section only tells us SRH TLV is defined in ietf-6man-segment-routing-header, nothing else. I think this section should be removed.

[ZA] Indeed, the current draft does not define any TLV for OAM purposes. However, section was added as future drafts may define OAM TLVs. However, based on your comments, the section has been removed in the new revision.

4. Section 4.3 Monitoring of SRv6 Paths
This section is a story or a use case. No specification is defined in this section. It should be removed or moved to an appendix.

[ZA] It is a use case.

5. Section 2.1 Abbreviations
ICMPv6 is defined in RFC4443. Why does this draft use it as multi-part ICMPv6 defined in RFC4884. This is confusing.

[ZA] Fixed the Section 2.1 Abbreviations. However, please note that the draft consistently mentions the RFC4443. Furthermore, the RFC4884 is equally applicable.

6. Section 4.1.3 Error Reporting
ICMPv6 is defined in ICMPv6 related RFCs. Does this section want to extend ICMPv6? If yes, I don't think this doc is the appropriate place. If no, why do we need this section? to emphasize the things that a router should do?

[ZA] No the section does not extend the ICMPv6. Inclusion is useful for the reader of the draft (for completeness). However, based on your comment we have removed the section.

Thanks

Regards … Zafar

<snip>