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

Hi Nick, 

Thank you for your review and comments! 

People from the two working groups (6man and v6ops) have given extensive reviews on this draft and provided their comments in the mailing list. Some of your comments are already covered and discussed. 

As people suggested, this draft is positioned as a problem statement draft on the issues of the HBH options header only. We have just uploaded this initial 00 version and will continue to working on it. 

The changes already made and those to be made are listed in my another email to the working group. Your suggestions on any further improvements are always welcomed. Thank you! 

Best regards, 
Shuping  

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard
> Sent: Tuesday, October 12, 2021 4:55 AM
> To: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-hbh-00.txt
> 
> internet-drafts@ietf.org 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
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops