Last Call Review of draft-ietf-spring-srv6-srh-compression-19
review-ietf-spring-srv6-srh-compression-19-secdir-lc-smith-2024-12-14-00

The “Compressed SRv6 Segment List Encoding” draft revision 19 specifies new
segment routing flavors and behaviors that enable compression of the SRv6 SID
list. The draft is written largely from the perspective of editing or
augmenting existing segment routing behaviors defined by RFCs 8402, 8986, and
8754. The draft reads like errata or change “pages” to these other
specifications and as such may be less accessible to readers not familiar with
the original specifications. Overall, the draft is well written, concise, and
introduces the reader to the subject matter effectively.

In summary, the draft is: READY WITH NITS

The following list contains areas where the authors may want to give more
attention:

The draft uses the FIB term extensively but doesn't list it in the terminology
section where other such terms that are defined in other RFCs and used in this
draft are listed.

Sections 4.1.5, 4.2.2, 4.2.3, 4.2.4, 4.2.6, 5.3 (last paragraph) appear to have
a spurious newline.

Section 4.2.8 uses R20.1 to refer to a one-line change to R20. In other parts
of the document a one-line change doesn't introduce a ".1" extension to the
line number. Possibly, this should just be "R20"?

Section 5.1 refers to "anycast" but doesn't cite a reference.

Section 5.3 the NEXT-CSID flavor SIDs are shown in an example using the form
"2001:db8:b1:10::" without introduction to what it is. Providing some
introductory text may improve readability such as "The SID 2001:db8:b1:10:: is
bound to ...".

Section 6.2 uses the abbreviation "AL" but doesn't describe where it is defined
and doesn't directly define it.

Section 6.2 refers to HMAC which may refer to a cryptographic MAC function. The
security considerations section doesn't describe the security significance of
the HMAC use. HMAC / SHA-1 may not be strong enough for many use cases.
Stronger SHA-256/512 may be required. The I-D doesn't describe the security
implications of the protocol given there are users that require SHA-256 or
higher strength.

Section 7 "S/that spans across multiple routing domains"/that spans multiple
routing domains"

Section 7.2 uses the variable "J" but it isn't clear if this is the same J that
is defined in Section 4.2 of [RFC8986].

Section 7.2 uses the word "learnt" which isn't found in the American English
dictionary.

Security Considerations - As this RFC updates previous SR RFCs it may be
appropriate to revisit assumptions made by earlier RFCs regarding the
appropriateness of security strength, algorithms used, and considerations for
PQC readiness.