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 <nore...@ietf.org> 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 -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
