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.