Hi Joel, WG,
I support this I-D and would like to see it published. I have a few
suggestions that the authors and WG could consider. FWIW I did not review
the pseudocode for correctness :)
## Suggestions
- A general reader might be tempted to know why two flavors exist? Perhaps
a few sentences in section 4 could be added.
- An operator might be looking for guidance on when to use which flavor and
with which C-SID lengths. Perhaps these are things better suited in
proposed srv6ops, or is it possible to add some high level operational
guidance here?
- Section 11, is there any guidance to these future documents that is worth
adding?
## Minor
- Consider adding one sentence to introduce SRv6 in the abstract.
- Consider adding text that the term LOC is used for SID locator in RFC
8986 alongside other terms.
- Section 5, RESERVED is not a BCP14 keyword, perhaps reword to use another
BCP14 keyword if you need a normative framing!
- Section 7, in Locator-Block B2/m, better to explicitly say what m is.
- Section 7.1, "it could be learnt via configuration or using a signaling
protocol", which signaling protocol are you thinking of?
- Table 1, there are some TBA in the list, which seems incorrect as they
have assigned values in the registry already, please use the values instead
of TBA! Also consider adding all columns as per the registry that includes
Hex, change control as well.
## Nits
- Expand SRv6 in Title
- Expand for following abbreviation
- PSP
- USP
- USD
- I find this style "The SPRING working group has observed that..." odd and
not suitable for standard track RFC.
- Section 7 title "Inter Routing Domains Compression" is unclear! Perhaps
"Compression in Multiple Routing Domains" or "Inter-Domain Compression"?
Thanks!
Dhruv
On Mon, Jan 22, 2024 at 7:58 PM Joel Halpern <[email protected]> wrote:
> (One of the other chairs pointed out that this had not gone to the list.
> So forwarding the announcement.)
>
> This tarts the WG last call on the above document.
>
> Thank you,
>
> Joel
>
>
> -------- Forwarded Message --------
> Subject: IETF WG state changed for draft-ietf-spring-srv6-srh-compression
> Resent-Date: Sun, 21 Jan 2024 11:25:02 -0800 (PST)
> Resent-From: [email protected]
> Resent-To: [email protected], [email protected],
> [email protected], [email protected]
> Date: Sun, 21 Jan 2024 11:25:02 -0800
> From: IETF Secretariat <[email protected]>
> <[email protected]>
> To: [email protected],
> [email protected]
>
>
> The IETF WG state of draft-ietf-spring-srv6-srh-compression has been
> changed
> to "In WG Last Call" from "WG Document" by Joel Halpern:
>
> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
>
> Comment:
> This starts the WG last call for this document. Please comment with support
> or opposition, and explanation of your perspective. Silence is not consent,
> and just "support" or "oppose" is not helpful. This call will run through
> the end of Feb 4, 2024. Yours, Joel Halpern - responsible Spring co-chair
>
> PS: I would appreciate a document shepherd from the WG for the bnext step.
> Email me if you are willing.
>
> _______________________________________________
> spring mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/spring
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
