This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

From a transport viewpoint:

Might be useful to note (e.g., in sec 8) that the lack of HBH options often pushes designers to consider using transport headers for this purpose, which is even more problematic.

Other general comments:

The last two sentences of the abstract seem redundant and can be omitted.

In Sec 1 and throughout, it is not clear that HBH packets go to the “control plane”, so much as do not stay in the hardware “fast path”. The slow-path can be implemented in the control plane or as a separate software capability; either way, this represents a substantially more limited path.

HBH packets sent to a software path create a bottleneck for their processing, where HBH packets can be used to DOS HBH processing. HBH packets sent to processing shared with the control plane can further DOS the control plane itself, impeding routing, monitoring, etc.

Sec 2 terminology normatively refers to a draft, then presumably this draft is coupled with that one for publication. The final RFC should not refer to a draft for terminology.

Sec 4 processing seems to assume ASICs vs P4 (SDN), where NPUs and FPGAs are also widely used. All but ASICs can be reconfigured, but that happens infrequently at best.

Sec 5 talks about assigning HBH packets to the control plane; it seems more accurate to assign them to slow-path processing, as (again) this may not necessarily coincide with the control plane.

Sec 6 refers to next header = 0; it might be useful to explain its meaning (that HBH options follow). The discussion of MPLS seems out of place; it would be useful to consider explaining its relation to IP better or consider omitting it.

Sec 8 provides a list of design principles, but it would be useful to explain how they might be achieved. E.g, the control plane can be protected by reserving capacity of the control plane processor for control plane operations, vs. (slow path) data plane operations. This section provides a core concept of the doc – that HBH options don’t need to be avoided completely. It needs beefing up and more discussion, both throughout and in summary. 

Sec 9 seems very brief and should be expanded a bit.

Sec 10 does not seem sufficient; this document might explain that existing methods for dealing with HBH options have existing security considerations as per these documents, but the approaches in Sec 8 and Sec 9 both need to be specifically and uniquely addressed in this doc.