Hi Erik, I just pushed revision -22 with the “updates” tag pointing to RFC 8754 and the corresponding explanatory text in the abstract, introduction, and section 4.2.
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/22/ I hope that this, together with the previous changes in revision -20, addresses all of your concerns on this document. Thanks, Francois On 4 Feb 2025 at 22:46:40, Francois Clad <[email protected]> wrote: > Dear Erik, > > Many thanks for reviewing this document. > > I am talking with my co-authors about your first DISCUSS item and will get > back to you shortly. > > We also made several changes in revision -20 to address the remaining > points of your review. These changes are listed below. > > Thanks, > Francois > > On 3 Feb 2025 at 02:03:07, Erik Kline via Datatracker <[email protected]> > wrote: > >> Erik Kline has entered the following ballot position for >> draft-ietf-spring-srv6-srh-compression-19: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> # Internet AD comments for draft-ietf-spring-srv6-srh-compression-19 >> CC @ekline >> >> * comment syntax: >> - https://github.com/mnot/ietf-comments/blob/main/format.md >> >> * "Handling Ballot Positions": >> - >> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> >> ## Discuss >> >> ### __general__ >> >> * Should this document formally update RFC 8754? >> >> The 128-bit values in the SRH when REPLACE-CSID is in use are very >> clearly >> not IPv6 addresses, and the SRH is described as a list of segments which >> are IPv6 addresses. >> >> To be clear: I have no objection to the REPLACE-CSID behavior, I'm just >> wondering if we should update 8754 since what was described as an IPv6 >> address is, when REPLACE-CSID is in use, just "128-bits of other >> meaning." >> > > Let me discuss this with my co-authors and come back to you. > > ### S2, S4, perhaps elsewhere >> >> * I think it should be noted for clarity that regardless of CSID flavor, >> the >> IPv6 address observable in the IPv6 Header.DA field is a valid SRv6 SID >> conforming to RFC 9602. >> > > Indeed. That's a good point to clarify. We added text in Section 4 per > your suggestion. > > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> # Internet AD comments for draft-ietf-spring-srv6-srh-compression-19 >> CC @ekline >> >> * comment syntax: >> - https://github.com/mnot/ietf-comments/blob/main/format.md >> >> * "Handling Ballot Positions": >> - >> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> >> ## Comments >> >> ### S4.1 >> >> * "An SR segment endpoint node instantiating a SID of this document with >> the NEXT-CSID flavor MUST accept any Argument value for that SID." >> >> What does this really mean? Is it trying to say that the node that >> encaps >> a package with the first CSID in the DA cannot perform any validation >> of the control plane information that told it which CSID/DA to use? >> Or something else? >> >> If this about the "shift and zero-pad" behavior in the following >> paragraph, >> trying to ensure that no unnecessary inspection of resulting CSID/DA, >> then I think that makes sense except that (a) it could be more clear and >> (b) it probably belongs at the end of the behavior-describing paragraph. >> > > RFC 8754 defines the SR segment endpoint node as the node that receives an > IPv6 packet, identifies the DA as a locally instantiated SID, and applies > the SID behavior. > > In the case of NEXT-CSID, the argument value is filled by the SR source > node with the subsequent CSIDs in the container. The quoted text means that > the SR segment endpoint node must not impose any restriction on what the SR > source node can put in the SID argument value. > > ### S4.2 >> >> * "A Locator-Block length of 48, 56, 64, 72, or 80 bits is recommended..." >> >> Just to be clear: you want this "recommended" to be lowercase? Put >> another >> way: should this be "RECOMMENDED"? >> >> I'm not sure it makes a significant difference either way >> (operationally); >> just checking. >> > > Yes, the lowercase is intended. This is operational guidance that should > not have any impact on the implementation or interoperability. > > ### S5.3 >> >> * Feel free to use the dedicate SID prefix from RFC 9602 Section 6 in your >> examples, if you wish. >> > > Thanks for the suggestion. In particular the `5f00:d0c::/32` prefix looks > really nice! But let's maybe stick to the usual documentation prefix until > one gets formally assigned for SRv6 SIDs documentation. > > ## Nits >> >> ### S4.1, S4.2 >> >> * "At high level" -> "At a high level" >> > > We fixed this in revision -20. > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
