Re: [v6ops] I-D Action: draft-ietf-v6ops-hbh-00.txt

[Nick Hilliard <[e-mail]>]

[e-mail] wrote on 11/10/2021 17:43:
>          Title           : Operational Issues with Processing of the Hop-by-Hop Options Header
> 	Filename        : draft-ietf-v6ops-hbh-00.txt

I'm struggling with this ID.

Section 1: there is nothing in this section which isn't already said in 
rfc9098.

Section 2 is an overly-detailed explanation of router control plane / 
forwarding plane interaction, but then changes to a general discussion 
about HBH, most of which is repetition of other ietf documents.

Section 3 is a restatement of some material from rfc8200.

Sections 4 and 5 are a restatement of chunks of rfc9098.

Section 6 is a statement of aspirations about potential use of HBH.

Section 7 is mostly a repetition of draft-hinden-6man-hbh-processing. 
It states a list of aspirations for HBH processing that, if anything, 
belong to a standards track document, but they're difficult to mandate 
in a standards document for reasons which have already been discussed at 
some length in the draft-hinden-6man-hbh-processing discussion.

Section 8 talks about a new HBH header scheme, but doesn't indicate 
anywhere what this means or what the assumed old HBH scheme is.

The problem is, material which has been restated from other IETF 
documents needs to be removed (e.g. sections 1, 3, 4, and 5).

Once this is done, there's not much left in this draft, and what's left 
is either not relevant to the core of the document (detailed discussion 
of forwarding hardware mechanisms) or else has been restated in other 
drafts, e.g. draft-hinden-6man-hbh-processing, or else doesn't fit 
together in this document (section 2, 8).

Ideally people want general EHs (i.e. not just HBHs) to work a bit 
better - we all agree on that.  If this is the case, then 
draft-hinden-6man-hbh-processing provides a much better-thought-through 
path than draft-ietf-v6ops-hbh.

Sorry if this review comes across as harsh, but there's been a good deal 
of discussion about several other documents on the v6ops mailing list 
recently, and it's just difficult to see what this document brings that 
is new.

Nick