Re: [Last-Call] Genart last call review of draft-ietf-6man-sids-03

[Reese Enghardt <[e-mail]>]

Hi Suresh,

Thank you for the replies.

Please see inline:

On 10/27/23 11:30, Suresh Krishnan wrote:
> […]
>
>> 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?

Yes, thank you.


>
>> 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?

I did see this text, but I could not get an answer to my question from 
this text, being a general reviewer without a lot of context on SRv6.

In my reading, either all SIDs are IPv6 addresses (which is what Section 
3 seems to imply), or all SIDs resemble IPv6 addresses but are not 
necessarily IPv6 addresses (which is what the Abstract seems to imply). 
Is it possible to make a direct statement saying which of the two is 
true, or am I making the wrong distinction?

If all SIDs are in fact IPv6 addresses, then I suggest changing text in 
the abstract such as:
OLD: "Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 
addresses and behave like them while exhibiting slightly different 
behaviors in some situations"
NEW: "Segment Identifiers (SIDs) used by SRv6 are IPv6 addresses which 
may exhibiting slightly different behaviors than specified in the IPv6 
Addressing architecture [RFC4291] in some situations"

If not all SIDs are IPv6 addresses, then I suggest changing text in 
Section 3 such as:
OLD: "[RFC8754] defines the Segment List of the SRH as a contiguous 
array of 128-bit IPv6 addresses"
NEW: "[RFC8754] defines the Segment List of the SRH as a contiguous 
array of 128-bit identifiers which resemble IPv6 addresses"

Of course, if the text is quoting from RFC8754, it might not be possible 
to make this change. My comment is not blocking, it's just a point of 
confusion for me.


>> "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.

I see. In this case, maybe it helps to simply remove the "Such" from the 
sentence, as it appears the sentence is talking about SIDs in general?


>> 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.

Sounds good, thanks!


Best,
Reese