Hi Reece, Thanks a lot for your review. Please find responses inline. > On Oct 26, 2023, at 3:46 PM, Reese Enghardt via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Reese Enghardt > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-6man-sids-03 > Reviewer: Reese Enghardt > Review Date: 2023-10-26 > IETF LC End Date: 2023-10-27 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is almost ready for publication as an Informational RFC, > pending some clarifications in the IANA Considerations and some text tweaks. > > Major issues: None. > > Minor issues: > > Abstract: > The abstract does not mention that the document allocates a Global Unicast > Prefix for SIDs, which seems like a major contribution of this document. I > suggest mentioning this contribution in the abstract. Will do. > > Section 1: > "SR segment endpoint nodes process a local segment present the Destination > Address of an IPv6 header." I have a hard time parsing this phrase, and I think > adding a preposition or an "-ing" somewhere would make it easier. Is this "SR > segment endpoint nodes processing a local segment present the Destination > Address of an IPv6 header." or "SR segment endpoint nodes process a local > segment which presents the Destination Address of an IPv6 header." or something > else? I will reword this to "SR segment endpoint nodes process a local segment present in the Destination Address of an IPv6 header” Does that clarify the intent? > > Section 3: > Are all SIDs IPv6 addresses? This section sounds like it implies that they are, > while the abstract says that they merely "resemble" IPv6 addresses. I suggest > clarifying this point in the document. I had attempted to address this with the following text in Section 3. Some of these elements may represent a local interface as described in Section 4.3 of [RFC8754] as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID". From this it follows that not all the SIDs that appear in the SRH are SRv6 SIDs as defined by [RFC8402]. Does that clarify further? > > "Such a SID is assigned to a node within a prefix defined as a Locator of > length L." Does "Such a SID" refer to the previous sentence, which talks about > SIDs with L+F+A < 128? If not, what is meant by "Such a SID"? "Such as SID" refers to the "Section 3.1. of [RFC8986] describes the format of an SRv6 SID…”. The padding piece you mentioned is still part of the definition from RFC8986 and was added to the draft since it was brought up as a question in 6man. > > IANA Considerations: > This document asks IANA to allocate a Global Unicast Prefix for SIDs. According > to Section 5.1 of RFC 5226, I suggest that this document explicitly identify > the namespace in which a value is to be allocated - The "Internet Protocol > Version 6 Address Space" registry has multiple prefixes marked as "Reserved by > IETF". According to RFC 3513, I assume this will be under the 1000::/4 prefix, > but I may be missing context here. There is a separate discussion ongoing with IANA on this and it appears to tend towards an allocation of the fbff::/16 block. I will update this in the next version of the draft. > > Nits/editorial comments: > > Section 3: > "Please note that [BCP198] does not override the rules in [RFC4291], but merely > limits where their impact is observed" Missing full stop at the end. Will fix. Thanks Suresh -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
