Early Review of draft-ietf-schc-protocol-numbers-00
review-ietf-schc-protocol-numbers-00-intdir-early-touch-2024-08-30-00

Although this request is being performed from an INTARA perspective, it
includes considerations at the Ethernet and transport layers.

Overall, the document is written assuming significant context of the related
SCHC documents. It would benefit from some review of that material, in brief,
to provide a more coherent stand-alone argument for the intended codepoints.

The case for an Internet protocol number is insufficient. The case for an
Internet protocol number should be based on the use of SCHC as a protocol
following the IP header, however this implies that there would be one IP header
that is not compressed followed by another that is. If that is desired, please
make that case; the current text does not.

The case for an Ethertype is more clear to me, but the discussion presented is
insufficient. The case should be based on the need for Ethernet equipment to
process SCHC packets differently from IPv4, IPv6, ARP, etc. This case needs to
be made that SCHC cannot be differentiated from IP traffic from the packet
alone and thus needs an indicator at the Ethertype layer. The current text does
not make that case.

The case for SCHC as a UDP port number is vacuous (TBD), and clearly
insufficient.

NOTE: of the above, the case for an Internet protocol number assignment seems
more likely, IF sufficient discussion can explain why SCHC-encoded packets
cannot be distinguished from IP packets, either from previous context or that
such context is not available.

The case for an Ethertype seems possible, but somewhat more challenging to make.

The case for a transport port number – UDP or otherwise – seems incorrect.
Speaking from the perspective of the transport ports review team, port numbers
identify services, not single “next” protocols. Although it might be useful
were that the case, it is historically not. So the question is whether a
service can negotiate use of SCHC – which is definitely preferable if possible.
E.g., TLS use can be negotiated and disabled if endpoints agree, so a single
assignment can support both secure and (where appropriate, e.g., in controlled
environments) insecure variants. It would be wise of SCHC could develop a
similar approach, e.g,, as part of the TLS negotiation, part of SCHC use
negotiation, or otherwise. Finally, if there is a specific tunnel mechanism
that uses SCHC, it might be eligible for a port assignment, as has been the
case for various IP tunnels. But it is very unlikely a case can be made for
SCHC as a port assignment absent a complete service definition.