Thanks Joel, Peter, et al. The WG last call is now complete (it was mainly being held during the appeal on the base document, and was ready a while ago). The document improved in the meantime which is great.
I have completed the write-up and the document has been submitted to the IESG for publication. Thanks, Chris. > On Oct 8, 2020, at 11:00 AM, Joel M. Halpern <j...@joelhalpern.com> wrote: > > Just to confirm, yes, that change Peter has made removing END.T resolves my > concerns. > Thanks, > Joel > > On 10/8/2020 9:38 AM, Peter Psenak wrote: >> Hi Chris, >> please see inline: >> On 02/10/2020 12:32, Christian Hoppsprotocol= application/pgp-signature >> wrote: >>> Thanks for the update, a couple issues remain. >>> >>> [ ] 7.1 and 8.1 >>> >>> The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are >>> defined differently (and probably incorrectly) than the other reserved bits. >>> Reserved bits "MUST" be set to zero, not "SHOULD", I believe. >> fixed. >>> >>> [ ] 11. Implementation Status >>> >>> I know you mentioned that the section should be removed, but how about >>> adding a note to the editor in the next revision e.g., "RFC Ed.: Please >>> remove this section prior to publication"? >> done >>> >>> [ ] 12.5. Sub-Sub-TLVs for SID Sub-TLVs >>> >>> This section needs to better conform to registry creation standards (see >>> https://tools.ietf.org/html/rfc8126). In particular there is no guidance. >> I have modified the section 12.5. >>> >>> It looks like there is more discussion from Joel on this draft, so I will >>> hold off on submission for that to resolve. >> I have removed the END.T in the latest version. The discussion with Joel is >> closed. >> thanks, >> Peter >>> >>> Thanks, >>> Chris. >>> >>>> On Sep 23, 2020, at 4:36 PM, Peter Psenak >>>> <ppsenak=40cisco....@dmarc.ietf.org> wrote: >>>> >>>> Hi Chris, >>>> >>>> thanks for your comments. >>>> >>>> Please see inline (##PP): >>>> >>>> On 18/09/2020 16:08, Christian Hoppsprotocol= application/pgp-signature >>>> wrote: >>>>> During my review and while doing the Shepherd writeup for >>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I >>>>> came up with the following comments: >>>>> 4.3 - Maximum H.Encaps MSD Type: >>>>> - what is the default if not advertised? >>>> >>>> ##PP >>>> added "or no value is advertised" as for other MSD types. >>>> >>>>> 6. Advertising Anycast Property >>>>> Should "Locator that is advertised..." be: >>>>> "An SRv6 Locator that is advertised..."? >>>>> or: >>>>> "A prefix/SRv6 Locator that is advertised..."? >>>> >>>> ##PP >>>> fixed. >>>> >>>>> 7.1 SRv6 Locator TLV Format >>>>> The R fields and their handling, are not defined. >>>> >>>> ##PP >>>> added >>>> >>>> >>>>> 8. Advertising SRv6 Adjacency SIDs >>>>> "must be" "in order to be correctly applied" -> "are" and ""? >>>> >>>> ##PP >>>> I replaced with: >>>> >>>> Certain SRv6 Endpoint behaviors [I-D.ietf-spring-srv6-network-programming] >>>> are associated with a particular adjacency. >>>> >>>> >>>>> 8.1. SRv6 End.X SID sub-TLV >>>>> "Other bits" -> "Reserved bits" -- labels should match >>>> >>>> ##PP >>>> fixed. >>>> >>>>> 8.2. SRv6 LAN End.X SID sub-TLV >>>>> I'm sympathetic to Bruno's comment, and so I think it would be better to >>>>> say: >>>>> Diagram: "System ID (1-6 octets)" and in text: >>>>> "6 octets" -> "System ID: 1-6 octets" >>>>> I see no reason to mess with this even if the commonly-implemented value >>>>> is 6 at >>>>> this point. IS-IS implementations that only support 6 octets are free to >>>>> only >>>>> support 6 in this sub-TLV as well. They won't be talking with other IS-IS >>>>> routers that are configured to have a non-6 octet system ID value. What >>>>> other >>>>> extension RFCs may or may-not do WRT this doesn't really matter I think. >>>> >>>> ##PP >>>> I have updated the text to match what is being used in RFC8667, section >>>> 2.2.2 >>>> >>>> >>>>> "Other bits" -> "Reserved bits" -- labels should match >>>> >>>> ##PP >>>> fixed >>>> >>>>> 11. Implementation Status >>>>> Does this section need a "RFC Ed.: Please Remove prior to publications"? >>>>> It >>>>> seems pretty wrong to document current status of implementations >>>>> permanently in >>>>> an Standards Track RFC. >>>> >>>> ##PP >>>> yes this section will be removed prior to publication. This is a standard >>>> procedure we follow. >>>> >>>>> 12. IANA Considerations >>>>> An odd space between "sub- TLV". >>>> >>>> ##PP >>>> fixed >>>> >>>>> 12.5. Sub-Sub-TLVs for SID Sub-TLVs >>>>> This section needs to better conform to registry creation standards (see >>>>> https://tools.ietf.org/html/rfc8126). >>>> >>>> ##PP >>>> I updated the IANA section format similar to RFC8667. >>>> >>>> >>>>> ID-NITS: >>>>> There are 19 instances of too long lines in the document, the longest >>>>> one >>>>> being 5 characters in excess of 72. >>>> >>>> ##PP >>>> fixed. >>>> >>>>> References: >>>>> Normative: >>>>> Published: RFC 8754 draft-6man-segment-routing-header >>>> >>>> ##PP >>>> fixed. >>>> >>>> >>>>> Out of date reference: [I-D.ietf-6man-spring-srv6-oam] >>>>> Out of date reference: [I-D.ietf-spring-srv6-network-programming] >>>> >>>> ##PP >>>> Whenever the new version of draft-ietf-lsr-isis-srv6-extension is >>>> published it picks the latest version, but as these drafts keep changing >>>> the reference may get out of date quickly. >>>> >>>> >>>> >>>>> Informative: >>>>> Published: RFC 8402 draft-ietf-spring-segment-routing >>>> >>>> ##PP >>>> fixed >>>> >>>> thanks, >>>> Peter >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>>> >>> >>> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
