Telechat Review of draft-ietf-spring-srv6-srh-compression-23
review-ietf-spring-srv6-srh-compression-23-intdir-telechat-muite-2025-03-10-01

I am an assigned INT directorate reviewer for
<draft-ietf-spring-srv6-srh-compression-23>. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/.

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

Comments:
Slightly updated late review.  Document has already passed IESG.

Link for reference IMPL-OSS-OPEN-SRV6 is empty and should probably be updated
before final publication.

Extensive interoperability testing has been done through EANTC, though the
documentation is not quite as extensive as an IETF Best Current Practice.

Section 6.2 contains the following:
   If an SR source node chooses to compress the SID list, one method is
   described below for illustrative purposes.  Any other method
   producing a compressed SID list of equal or shorter length than the
   uncompressed SID list MAY be used.

Should this be updated to something like:

   If an SR source node chooses to compress the SID list, one method is
   described below for illustrative purposes.  Any other method
   producing a compressed SID list of equal or shorter length than the
   uncompressed SID list MAY be used if specified in a future draft or
   draft revision.

The rationale for such a change is that if the encoding method is not
specified, then interoperability maybe problematic because choosing the
appropriate decoding algorithm may be difficult. The current compression method
compresses by not keeping copies of some repeated data blocks.  It shares some
similarities with run length encoding.  Run Length Golomb Rice encoding may be
better in compression efficiency than the current option, but might require
more processor cycles.