Hi Ketan,
Thank you for your response and guidance.
Some further questions/comments below marked with [rfced].
>
> 4) <!-- [rfced] The following text from Section 2 may require
> clarification:
>
> "As specified in Sections 2.4.4 and 2.4.4.2 of [RFC9830],
> validation of an explicit path encoded by the Segment List sub-TLV
> is beyond the scope of BGP and performed by the Segment Routing
> Policy Module (SRPM) as described in Section 5 of [RFC9256]."
>
> The term "Segment Routing Policy Module (SRPM)" doesn't appear in
> [RFC9256].
>
> -->
>
> KT> It should be RFC9830
[rfced] We believe the citation in the sentence following should be updated as
well (and have made the update). Please review and let us know if this is in
error.
>
>
>
> 5) <!--[rfced] The following text led us to believe that the subsection
> titles of Section 2 would match the Type names listed in Section
> 2 itself: but they do not. Please review and let us know if a
> closer 1:1 matchup is desired between these.
>
> Original:
> [I-D.ietf-idr-sr-policy-safi] specifies Segment Type Sub-TLVs for the
> segment types A and B. The following sub-sections specify the sub-
> TLVs used for encoding each of the other Segment Types above.
>
>
> KT> They look ok to me, but perhaps I don't follow your point. Could you
> please illustrate with an example?
>
>
> -->
[rfced] Sorry for any confusion. Just curious if the wording should be made
the same in the “names” of the Types. We see:
Original ToC:
2. Segment Type Sub-TLVs . . . . . . . . . . . . . . . . . . . . 3
2.1. Segment Type C - SR-MPLS Prefix SID for IPv4 . . . . . . 4
2.2. Segment Type D - SR-MPLS Prefix SID for IPv6 . . . . . . 5
2.3. Segment Type E - SR-MPLS Adjacency SID for IPv4 with an
Interface ID . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Segment Type F - SR-MPLS Adjacency SID for IPv4 with an
Interface Address . . . . . . . . . . . . . . . . . . . 6
2.5. Segment Type G - SR-MPLS Adjacency SID for IPv6 with an
Interface ID . . . . . . . . . . . . . . . . . . . . . . 7
2.6. Segment Type H - SR-MPLS Adjacency SID for IPv6 with an
Interface Address . . . . . . . . . . . . . . . . . . . 9
2.7. Segment Type I - SRv6 END SID as IPv6 Node Address . . . 9
2.8. Segment Type J - SRv6 END.X SID as an Interface ID . . . 11
2.9. Segment Type K - SRv6 END.X SID as an Interface
Address . . . . . . . . . . . . . . . . . . . . . . . . 12
Original list in Section 2:
Type A: SR-MPLS Label
Type B: SRv6 SID
Type C: IPv4 Prefix with optional SR Algorithm
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS
Type E: IPv4 Prefix with Local Interface ID
Type F: IPv4 Addresses for link endpoints as Local, Remote pair
Type G: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SR-MPLS
Type H: IPv6 Addresses for link endpoints as Local, Remote pair
for SR-MPLS
Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6
Type J: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SRv6
Type K: IPv6 Addresses for link endpoints as Local, Remote pair
for SRv6
Perhaps the section titles of Section 2’s subsections should be updated as
follows to match their descriptions in the ToC above (or vice versa (with the
list in Section 2 being updated to match the styling in the original ToC))?
For example, make the section titles be:
2.1. Segment Type C: IPv4 Prefix with Optional SR Algorithm
2.2. Segment Type D: IPv6 Global Prefix with Optional SR Algorithm for
SR-MPLS
2.3. Segment Type E: IPv4 Prefix with Local Interface ID
2.4. Segment Type F: IPv4 Addresses for Link Endpoints as Local, Remote
Pair
2.5. Segment Type G: IPv6 Prefix and Interface ID for Link Endpoints as
Local, Remote Pair for SRMPLS
2.6. Segment Type H: IPv6 Addresses for Link Endpoints as Local, Remote
Pair for SR-MPLS
2.7. Segment Type I: IPv6 Global Prefix with Optional SR Algorithm for
SRv6
2.8. Segment Type J: IPv6 Prefix and Interface ID for Link Endpoints as
Local, Remote Pair for IPv6
2.9. Segment Type K: IPv6 for Link Endpoints as Local, Remote Pair for
SRv6
If this close of a relationship is not necessary/desired, it is fine to leave
them as they are.
>
>
> 7) <!-- [rfced] We note that Section 2.4.4.2.4 of [RFC9830] uses the term
> "SRv6 SID Endpoint Behavior and Structure" rather than "SRv6
> Endpoint Behavior and SID Structure". Please let us know if/how
> these uses may be made consistent.
> -->
>
> KT> I would prefer the latter, but then we'll also need to make it consistent
> in RFC9830 (e.g.,
> https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2.4 )
>
[rfced] We have updated to use the latter throughout this document and
consistently throughout RFC-to-be 9830. Please review the use in both
documents (as an author of each) and reply to each specific email thread with
any further updates and/or approval of the changes. Note that we also changed
some instances in which “or” was used instead of “and” to be “and”
consistently. Please let us know if this was in error.
>
>
> 8) <!--[rfced] Please review the entries in Table 1 in light of this response
> regarding the names of sub-TLVs from Ketan when we discussed this topic for
> RFC-to-be 9830:
>
> Ketan:
> "The names of the segments (titles) are to be "Segment Type X" while the name
> of the sub-TLVs are to be "Type X Segment sub-TLV" (I've seen both sub-TLV
> and Sub-TLV - either is OK but we should have been consistent). The "Type-1"
> is actually "Type A Segment sub-TLV"."
>
> If updates are necessary to the corresponding IANA registry, we will
> communicate them on your behalf once AUTH48 concludes.
>
> KT> Yes, please apply the same to this document as well for consistency.
> However, I notice that the IANA sections in both 9830 and 9831 are not
> matching the sub-TLV names. Could you please fix that?
> https://www.rfc-editor.org/authors/rfc9830.html#section-6.5
>
>
>
> —>
[rfced] We have made the necessary updates to Table 1 and will communicate
these changes to IANA once AUTH48 completes.
With regard to RFC-to-be 9830: We believe you are referring to values 1 and 13
in Table 5 (of Section 6.5) and have updated the document and will communicate
this change to IANA along with the changes to this document (once AUTH48 for
RFC-to-be 9831 concludes).
We ask again that you review the changes to RFC 9830 and communicate your
approval or need for further updates in that email thread (for other authors’
benefit as well as the AUTH48 archive).
Any other changes have been incorporated as requested. Please review carefully
as we do not make changes once the document is published as an RFC.
The files have been posted here:
https://www.rfc-editor.org/authors/rfc9831.txt
https://www.rfc-editor.org/authors/rfc9831.pdf
https://www.rfc-editor.org/authors/rfc9831.html
https://www.rfc-editor.org/authors/rfc9831.xml
The relevant diff files have been posted here:
https://www.rfc-editor.org/authors/rfc9831-diff.html (comprehensive)
https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9831-auth48diff.html (AUTH48 changes
only)
https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html (side by side)
The AUTH48 status page for this document can be found here:
https://www.rfc-editor.org/auth48/rfc9831
The relevant cluster information can be found here:
https://www.rfc-editor.org/cluster_info.php?cid=C534
Thank you.
RFC Editor/mf
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
