[IPv6]Éric Vyncke's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-comp-rtg-hdr-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-08

Thank you for the work put into this document. I do like the idea of
compressing SRH-like header, but the document has room for improvements.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Bob Hinden for the shepherd's detailed write-up including the
WG consensus *but* it lacks the justification of the intended status (and IMHO
experimental is the right one).

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Section 5

`Decrement the IPv6 Hop Limit.` what do to when hop limit is 0 ? Is there a
deviation from RFC 8200 section 3, else why repeating this step ?

## Section 7

It is not clear to me why this document needs to make an allowance for
intermediate nodes (sic) that verify transport layer checksums. Transport layer
checksums are expected to be verified by the Transport layer endpoints and not
in the network. So since when the Internet architecture has changed to take
care of `it prevents intermediate nodes from verifying transport layer
checksums`? Actual references are required for such statement. And,
explanations should be given whether this "sentence" helps RFC 7258 pervasive
monitoring perhaps in the security considerations section.

## Section 11

While not a real DISCUSS criteria, I am really surprised to see an IPv4-like
notation for CRH SID.

## Section 12

As AH is end-to-end, intermediate nodes do not have the shared secret, hence
`The CRH is not compatibile with AH processing at intermediate nodes.` is
useless and confusing. Please remove. Very similar to the DISCUSS about section
7.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# COMMENTS (non-blocking)

## Abstract

Can we really write `deployed` for an experimental I-D?

## Section 1

s/to its destination/to its destination(s)/ (think multicast/anycast). Twice in
the section ;)

Suggest to move the motivation to its own section.

## Section 3

Any recommendation on when to do `The first CRH SID in the path can be omitted
from the list.`?

What is the expected behavior of any CRH-aware router and final node(s) when
`the Type- specific data field MUST be padded with zeros` is not respected ?

## Section 4

Can the IPv6 address in the CRH-FIB be a link-local or multicast or can only be
a unicast ? Section 5 gives some more explanations, but an early one would be
better.

## Section 5

The first bullet can probably be removed as it is the normal behavior of any
IPv6 node per RFC 8200.

`If Hdr Ext Len indicates that the CRH is larger than the implementation can
process, ` suggest using code 6 per
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5

While wasting octets with too large CRH (i.e., larger than the minimum length)
is a bad thing, does it deserve to discard the packet on transit ? Why not
requesting the source to enforce this mimimum length?

`If the search does not return a CRH-FIB entry` is the code 0 the most suitable
code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destination
unreachable' ?

`If Segments Left is greater than 0` this will always be the case per first
bullet `If Segments Left equals 0` ;-)

The reader will welcome a justification of `CRH-FIB entry contains a multicast
address, discard the packet and`.

## Section 6

I guess that this is linked to RFC 4302 (AH), so, please state this clearly.

## Section 7

Is it about `Destination Address Transparency` or privacy ?

## Section 8

`Each CRH SID is processed by exactly one node.` isn't it rather "Each CRH SID
is processed by exactly one CRH-configured router whose one address matches the
packet destination address" ?

## Section 9

The title should rather be "operational considerations"

What are the "representations described herein" in ` It is recommended that the
experimental versions of PING use the text representations described herein` ?
Is it about section 11 ? Then please add a forward reference.

## Section 10

This is the usual considerations about ICMP, please consider to remove this
section. Or refer for section 5 of RFC 4443.

## Section 11

Beside the above semi-DISCUSS, please state that hexadecimal should be in lower
case.

## Section 12

`The Source Address does not identify an interface on a trusted node.` is there
any hint how this can be done ? How will it scale if all CRH-enabled router
must know all the specific address of all trusted nodes ? The same scalability
issue for `The ACL discards packets whose source address identifies an
interface on a trusted node.`

## Section 13

If the Wireshark/tcpdump modifications (cited in section 9) are public, then
references to code will be welcome.

`Interoperability among these implementations has not yet been demonstrated.`
should rather be in section 14 'experimental results'

## Section 14

I am indeed very curious to see the experimental result of
```
Mechanism used to populate the FIB
Scale of deployment
```
even if the text states in one year after publication as an RFC, this work
started back in 2019 and was adopted in 2023, do we already have some results ?

What are the possible next steps as seen by the authors / 6MAN WG is the
experiment is assumed to be successful ? And what are the criteria to declare a
successful experiment ?

# NITS (non-blocking / cosmetic)

## Section 12

s/This is becasue /This is because/