IPv6 Hop-by-Hop Options Processing Procedures
draft-ietf-6man-hbh-processing-20

Many thanks to Peter Yee for his reviews.  

Section 8, paragraph 4: Nit:  Echoing a concern that Peter Yee raised, I feel like this paragraph could be restructured a little to make it clear that this concern is not specific to this draft.  My suggestions is to change the first sentence to: 'Although this is not specific to this draft, it should be noted that Internet protocol processing needs...'.  And then remove the second to last sentence in the paragraph.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-6man-hbh-processing-17

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

Many thanks for this writeup. It is well written and a nice read to explore the wonderful opportunities and associated deep dark secrets embodied with HbH options.

In the COMMENTS section i have added a series of comments with additional context. 

I hope this review and the various observations provide a way to help improve the document.

One question i had at the end of reading the draft, is if a transit node may for performance optimization reorder, whiteout changing or removing options that are enclosed within the HbH header? Why? Maybe a particular implementation is interested in a subset of options and prefers to see them at the beginnings of the HbH header for hardware optimization when steering the packet through the available internet paths? 

G/


#DETAILED COMMENTS
#=================

13	   This document specifies procedures for how IPv6 Hop-by-Hop options
14	   are processed in IPv6 routers and hosts.  It modifies the procedures
15	   specified in the IPv6 Protocol Specification (RFC 8200) to make
16	   processing of the IPv6 Hop-by-Hop Options header practical with the
17	   goal of making IPv6 Hop-by-Hop options useful to deploy and use in
18	   the Internet.  When published, this document updates RFC 8200.


The word "practical" in this context can be improved for clarity and precision. A better word might be "efficient" or "feasible," which conveys the intention to make the processing of IPv6 Hop-by-Hop Options more manageable and effective in real-world deployments.

similar use of the word practical was observed in the introduction section also.

117	   *  Fast Path: A path through a router that is optimized for
118	      forwarding packets.  The Fast Path might be supported by
119	      Application Specific Integrated Circuits (ASICs), a Network
120	      Processor (NP), or other special purpose hardware.  This is the
121	      usual processing path within a router taken by the forwarding
122	      plane.

The word "usual" in this context is appropriate, but "typical" or "standard" might be better choices to convey the intended meaning more clearly. 

139	   NOTE: [RFC6192] is an example of how designs can separate control
140	   plane and forwarding plane functions.  The separation between
141	   hardware and software processing described in [RFC6398] does not
142	   apply to all router architectures.  However, a router that performs
143	   all or most processing in software might still incur more processing
144	   cost when providing special processing for Hop-by-Hop options.

How about a slight rewrite of the section to enhance its readability:

"Note: [RFC6192] provides an example of how designs can separate control plane and forwarding plane functions. The separation between hardware and software processing described in [RFC6398] does not apply universally to all router architectures. However, routers that perform all or most processing in software may still incur higher processing costs when providing special handling for Hop-by-Hop options."

163	   *  If a subset of packets in a flow were to include Hop-by-Hop
164	      options, this could introduce a potential to increase the number
165	      of re-ordered packets and the re-ordering distances of the packets
166	      delivered to the destination.  This might result when the
167	      Extension Header was included in only some packets, or if a
168	      specific Hop-by-Hop option required different processing for some
169	      packets in a flow.  Significant reordering of the packets
170	      belonging to a flow can impact the performance of upper layer
171	      protocols and needs to be avoided.

It took me few times reading this section to fully grasp the intent. 
I tried to slightly reword the section for convenience:

"If a subset of packets within a flow includes Hop-by-Hop options, this may lead to an increased number of reordered packets and greater reordering distances for packets delivered to the destination. Such reordering could occur if the Extension Header is included only in some packets, or if a specific Hop-by-Hop option necessitates different processing for certain packets within the flow. Significant reordering of packets within a flow can negatively impact the performance of upper-layer protocols and should therefore be avoided.
"

173	   *  Packets could include multiple Hop-by-Hop options.  Too many
174	      options could make the previous issues worse by increasing the
175	      resources required to process them.  The total size of the options
176	      determines the number of header bytes that might need to be
177	      processed.  Measurements [Cus23a] show that the probability of
178	      successful transmission is currently higher for packets that
179	      include Options when it results in a short total Extension Header
180	      (EH) Chain size (e.g., less than 40 bytes).

s/previous/aforementioned/

217	   The main issues remain:

s/issues/concerns/

285	   "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
286	   clarified how intermediate nodes should process Extension Headers.
287	   This document is generally consistent with [RFC7045], and was raised
288	   as an issue for discussion when [RFC2460] was updated and replaced by
289	   [RFC8200].  This document updates [RFC8200] as described in the next

For clarity maybe 'this document' should be more explicit that it is about draft draft-ietf-6man-hbh-processing-17 and not about RFC7045, which was what i understood when i first read this section, and had to re-read the text again. i tried too come up with an text blob to clarify this, but i couldn't unfortunately

331	   It is expected that the Hop-by-Hop Options header will be processed
332	   by the destination.  Hosts SHOULD process the Hop-by-Hop Options

Earlier in the document it was mentioned that the destination address is multicast, and that there may be multiple destinations that process the packet. The text here seems to imply that there is only a single destination. Hence maybe 

s/destination/destination(s)/

469	   DISCUSSION

Is this section intended like this for the rfc-to-be, or is this to trigger discussions somewhere in the WG?

516	   A possible approach to implementing this is to maintain a lookup
517	   table based on Option Type of the IPv6 options that can be processed
518	   at full forwarding rate.  This would allow a router to quickly
519	   determine if an option is supported and can be processed.  If the
520	   option is not supported, then the router processes the option as
521	   described in Section 5.1 of this document.

Do we need this paragraph? Can it be left out (i do not have strong feelings if section remains though)? Implementers will do whatever they do to comply with their technology to select/identify those options they are instructed to process

534	   *  New Hop-by-Hop options SHOULD be designed to ensure the router can
535	      process the options at the full forwarding rate.  That is, they
536	      should be simple to process (see Section 5.2).

I am not sure that the keyword here is 'simple to process'. It seems that the requirement is that it can be processed in 'fast path by hardware' maybe?

563	   The general issue of robust operation of packets with new Hop-by-Hop
564	   options is described in Section 6.1 below.

s/issue/concern/

568	   Recent measurement surveys (e.g., [Cus23a]) show that packets that
569	   include Extension Headers can cause the packets to be dropped by some
570	   Internet paths.  In a controlled domain, routers can be configured or
571	   updated to provide support for any required Hop-by-Hop options.

in an earlier part of the text the term 'limited domain' was used. Would using this term be appropriate here also?

573	   The primary motivation of this document is to make it more practical
574	   to use Hop-by-Hop options beyond such a single domain, with the

Same as the previous comment. Is the text suggesting a limited domain is intended.

# Jim Guichard, RTG AD, comments for draft-ietf-6man-hbh-processing-17. All comments provide indits line numbers from v-17 of the document.

84	   An IPv6 packet includes Hop-by-Hop options by including a Hop-by-Hop
85	   Option header.  The current list of defined Hop-by-Hop options can be
86	   found at [IANA-HBH].  The focus for this document is to set the
87	   minimum requirements for router processing of Hop-by-Hop options.

Jim> The previous paragraph says that the document has the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts. However, the above does not mention hosts (?). Is this just an omission in the text or is the focus only for routers and therefore the previous paragraph is inaccurate? Please clarify.


111	   *  control plane: IPv6 routers exchange control information through
112	      the control plane.  This processes the management and routing
113	      information exchanged with other routers.  Routers process fields
114	      contained in packet headers.  However, they do not process
115	      information contained in packet payloads.

Jim> Are the last two sentences accurate in the context of a control plane definition? While both sentences are true they do not seem relevant to the control plane.

309	   When a packet includes one or more Extension Headers, the Next Header
310	   field of the IPv6 Header does not identify the transport protocol.

Jim> Wouldn’t it be better to say ‘what’ the Next Header field indicates rather than what it ‘does not’. There are lots of things it ‘does not’ indicate.

(I realized I had forgotten to capture one point while transcribing my notes. This updated ballot adds one more point, right at the end.)

This document uses a lot of words to say what is ultimately a fairly simple message. It's also an important message, so I think it's worth the time to communicate it clearly; hence the effort put into this review. (The quote attributed to Pascal, to the effect of "I am sorry I have written you a long letter, I did not have time to write you a short one" might apply here.)

As far as I can tell, the spec's TL;DR is:

Routers:

- SHOULD process HbH options as long as they can do so without compromising 
  forwarding rate.
- If it would compromise forwarding rate, they should triage the HbH 
  options they process. (Details of triage not specified other than
  letting the operator configure HbH options to respect/ignore.)
- Can ignore the whole HbH header by default, or can process it but use 
  configuration to control what individual HbH options are processed.
- MUST NOT drop a packet just because it contains a HbH header.
- SHOULD make the list of HbH options that are processed configurable.
	
- Concerning the RA option, if processing it at all,
	- "MUST protect itself from infrastructure attack".
	- Shouldn't bother the control plane for an RA that has no Value field
	  of interest.
	
Hosts when receiving:

- SHOULD process HbH headers, and process all options within
- But may choose not to process them (e.g. constrained hosts)
- For any HbH header not processed, they MUST (Section 5.1) behave as if 
  it wasn't present.
	  
Hosts when sending:

- SHOULD "use a method that is robust".
- MAY include more than one HbH option.
	
I feel fairly strongly that this document would be more valuable if it were less expository, more prescriptive, and shorter -- "crisper", if you like. However, my concerns don't rise to the level of blocking publication, so I've captured some specific and potentially actionable points in comments, and I understand that the authors' preferences may not be the same as mine, or that they may not have the appetite for a large rewrite. On the other hand, if you're up for the challenge, I'm willing to contribute more effort.

Note that not all of my comments are of that nature, many relate to correctness and accuracy -- so even if you completely disagree with my editorial point of view, please look over the rest of them.

## COMMENT

### Section 3, cut-and-paste error?

   *  control plane: IPv6 routers exchange control information through
      the control plane.  This processes the management and routing
      information exchanged with other routers.  

So far so good.

                                                 Routers process fields
      contained in packet headers.  However, they do not process
      information contained in packet payloads.

This sentence is a verbatim copy of a sentence in the definition of "forwarding plane". Is it a cut-and-paste error? It doesn't seem relevant to a definition of the control plane.

### Section 4, rewrite for clarity, add informative reference

The pronouns and determiners in the last couple of paragraphs make it hard to nail down what they mean. I think a simple rewrite to add more specificity would help. Assuming I've understood your meaning correctly, something like this,

OLD:
   "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
   clarified how intermediate nodes should process Extension Headers.
   This document is generally consistent with [RFC7045], and was raised
   as an issue for discussion when [RFC2460] was updated and replaced by
   [RFC8200].  This document updates [RFC8200] as described in the next
   section and consequently clarifies the description in Section 2.2 of
   [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].

   The document defines a set of procedures for the Hop-by-Hop Options
   header that are intended to make the processing of Hop-by-Hop options
   practical in modern transit routers.  The common cases are that some
   Hop-by-Hop options will be processed across the Internet, while
   others will only be processed within a limited domain [RFC8799]
   (e.g., where a specific service is made available in that network
   segment that relies on one or more Hop-by-Hop options).

NEW:
   "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
   clarified how intermediate nodes should process Extension Headers.
   The present document is generally consistent with [RFC7045], and
   addresses an issue that was raised for discussion 
   when [RFC2460] was updated and replaced by
   [RFC8200].  This document updates [RFC8200] as described in the next
   section and consequently clarifies the description in Section 2.2 of
   [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].

   This document defines a set of procedures for the Hop-by-Hop Options
   header that are intended to make the processing of Hop-by-Hop options
   practical in modern transit routers.  The common cases are that some
   Hop-by-Hop options will be processed across the Internet, while
   others will only be processed within a limited domain [RFC8799]
   (e.g., where a specific service is made available in that network
   segment that relies on one or more Hop-by-Hop options).

Since you allude to "an issue that was raised for discussion", it also wouldn't go amiss to provide an informative citation to the relevant list thread.

### Section 5.1, use the RFC 8200 words

Suggested rewording, both for correctness and to use the language of RFC 8200:

OLD:
   [RFC8200] also requires that a Hop-by-Hop Options header only appear
   once in a packet.

NEW:
   [RFC8200] also requires that a Hop-by-Hop Options header appear at most
   once in a packet.
   
### Sections 5.1, 5.1.1, clarity

You juxtapose a quote from RFC 8200 that says (my paraphrase, with BCP 14 keyword added to be provocative) "routers SHOULD NOT process the HbH header unless explicitly configured to do so", next to a new requirement that "clarifies that a configuration could control whether processing skips any specific" HbH option. I'll paraphrase that one too, again inserting a BCP 14 keyword, as "routers MAY instead process the HbH header by default while allowing configuration to disable specific options."

I guess those two things are compatible, but I had to do too much work to extract that interpretation and I'm not even confident that's really what you're trying to say. Can you confirm that it is? 

As a follow-up, if my paraphrase is right, how do you reconcile Section 5.1 where you say "Routers SHOULD process the Hop-by-Hop Options header" with (my paraphrase of) RFC 8200? You might reply that I've changed the meaning of Section 5.1 by omitting "using the method defined in this document", but if so I think you should rephrase the Section 5.1 language for clarity, as in,

OLD:
   Routers SHOULD process the Hop-by-Hop Options header using the 
   method defined in this document

NEW:
   Routers that process the Hop-by-Hop Options header SHOULD do so 
   using the method defined in this document.
   
On the other hand, if you intend that "Routers SHOULD process the Hop-by-Hop Options header", I think you have more work to do in Section 5.1.1, as discussed above.

### Section 5.2, first HbH option

The first couple of paragraphs appear to privilege the first HbH option compared to the rest. Is this deliberate? Can you help me understand why, if so?

For example, 

   A router configuration needs to avoid vulnerabilities that arise when
   it cannot process the first Hop-by-Hop option at full forwarding
   rate.  A router SHOULD NOT therefore be configured to process the
   first Hop-by-Hop option if this adversely impacts the aggregate
   forwarding rate.  A router SHOULD process additional Hop-by-Hop
   options, if configured to do so, providing that these also do not
   adversely impact the aggregate forwarding rate.

When I unpack this, how is it different from (my text):

   A router configuration needs to avoid vulnerabilities that arise when
   processing of a Hop-by-Hop option would prevent it from forwarding at
   full forwarding rate.  A router SHOULD process Hop-by-Hop options, if
   configured to do so, providing that these do not adversely impact the
   aggregate forwarding rate.

The primary change in my rewrite was to cut

   A router SHOULD NOT therefore be configured to process the
   first Hop-by-Hop option if this adversely impacts the aggregate
   forwarding rate.  
   
As far as I can tell the rewrite is semantically the same, but I'm concerned that I have missed something, otherwise, why would you have put in that special mention of the first option? :-(

One interpretation I came up with after reading it a few times is that what you mean is something like "when it cannot process even a single Hop-by-Hop option at full forwarding rate". Does that get at your intent? I appreciate that practically speaking, most forwarding code will go through the options serially starting with the first, but not only is that not a requirement, but in some of your other text you drive home the message that the order of processing is not guaranteed. So, I think you should be careful to separate that assumption from what you're trying to specify.

This is only one example. Another is the first paragraph,

   A source creating packets with a Hop-by-Hop Options header SHOULD use
   a method that is robust to network nodes processing only the first
   Hop-by-Hop option that is included in the packet, or that forward
   packets without the option being processed (see Section 6.1).
   
I would've expected something more like,

   A source creating packets with a Hop-by-Hop Options header SHOULD use
   a method that is robust to network nodes selectively processing only 
   some of the
   Hop-by-Hop options that are included in the packet, or that forward
   packets without the option(s) being processed (see Section 6.1).

As it is, a close reading of the sentence tells me it's fine if the method is *not* robust to network nodes that process only the second option, for example.

This isn't a full scrub of the section, e.g. the fourth paragraph has "further" (after what? The first? The last one successfully processed?) 

### Section 5.2, including more than one HbH option

I found "A source MAY, based on local configuration, include more than one Hop-by-Hop option" peculiar, given that there's never been a restriction on that in the past (has there?), i.e. you're granting permission for something that was always allowed, so... thanks? I think I see what you're doing, which is to subtly throw shade on the idea of including more than one HbH option, but if you want to do that, why do it subtly? E.g., you could go whole hog with something like

   A source SHOULD NOT include more than one Hop-by-Hop option, although
   it MAY do so based on local configuration. In the latter case it might
   wish to restrict the size...

### Section 5.2, clarity

OLD:
   If a router is unable to process any Hop-by-Hop option (or is not

NEW:
   If a router is unable to process a given Hop-by-Hop option (or is not

### Section 5.2, sense of "any" is underdetermined

   This document modifies this behaviour for the "01", "10", and "11"
   action bits, so that if a router is unable to process any Hop-by-Hop
   option (or is not configured to do so), it SHOULD behave in the way
   specified for an unrecognized Option Type when the action bits were
   set to "00".  It also modifies the behaviour for the "10" and "11"

Is "any Hop-by-Hop option" supposed to mean "any given HbH option" or is it supposed to mean "no HbH option"? I think it's the former, in which case, I suggest the change.

### Section 5.2, clarity, standalone patch

   This document modifies this behaviour for the "01", "10", and "11"
   action bits, so that if a router is unable to process any Hop-by-Hop
   option (or is not configured to do so), it SHOULD behave in the way
   specified for an unrecognized Option Type when the action bits were
   set to "00".  
...   
   The modified text for "01", "10", and "11" values is:

       01 - MAY discard the packet. Nodes should not rely on routers
            dropping these unrecognized Option Types.

       10 - MAY discard the packet 
...
       11 - MAY discard the packet 
...

And as a reminder (to me, at least!), 00 is:

      00 - skip over this option and continue processing the header.
      
I had to go over this several times before I finally worked out that the modified text for the three values quoted above is not actually in conflict with the SHOULD in the first quoted paragraph. While puzzling over it, I also noticed that even though all three values are modified to permit discard, only the first includes the sentence "Nodes should not rely on routers dropping these unrecognized Option Types".

It seems to me that even though it would make the document more verbose, and isn't strictly mandatory for technical correctness upon careful reading, it would be helpful for clarity to spell things out more explicitly, as in,

NEW:
   The modified text for "01", "10", and "11" values is:

       01 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured. 

       10 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured and, regardless of whether or not the
            packet's Destination Address was a multicast address, and if
            the packet was discarded, MAY send an ICMP Parameter
            Problem, Code 2, message to the packet's Source Address,
            pointing to the unrecognized Option Type.

       11 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured and, only if the packet's Destination
            Address was not a multicast address, and the packet was
            discarded, MAY send an ICMP Parameter Problem, Code 2,
            message to the packet's Source Address, pointing to the
            unrecognized Option Type.

   Nodes should not rely on routers dropping unrecognized Option Types.
   
I added a SHOULD clause for each. I also added "if so configured" to the MAY parts, it's unclear to me if that's overreach or helpful clarification of intent since I don't know if you intended the MAY to cover other cases too. Finally, I factored out the "should not rely on" sentence so that it doesn't appear to apply only to the 01 case.

Apart from simple readability, the other argument I'd give in favor of making this change (or one like it) is that in this kind of patch-type approach to updating a base document (which is what this is, despite the fact you haven't used OLD/NEW blocks), it's desirable for the patched base document to at least potentially stand alone. 

### Section 5.2, "a multicast address", plus RFC 2119 keyword

I have two concerns about

   When a node sends an ICMP message in response to a packet with a
   multicast address, this could be exploited as an amplification
   attack.  This is particularly problematic when the Source Address is
   not valid (which can be mitigated to varying degrees by using a
   reverse path forwarding (RPF) check).  A node SHOULD only send ICMP
   messages in response to a packet with a multicast address when this
   is enabled for the specific Source Address and/or the group
   Destination Address.

The first concern is that when you write "a packet with a multicast address", it's not clear, until one reads the final sentence, that you mean either the source address or the destination address. I suggest spelling it out explicitly. The second concern is that although your intent with "SHOULD only" is clear enough, it doesn't fit the RFC 2119 definition of SHOULD. A possible rewrite to cover both concerns is,

NEW:
   When a node sends an ICMP message in response to a packet with a
   multicast source or destination address, this could be exploited as 
   an amplification
   attack.  This is particularly problematic when the Source Address is
   not valid (which can be mitigated to varying degrees by using a
   reverse path forwarding (RPF) check).  A node SHOULD NOT send ICMP
   messages in response to a packet with a multicast source or 
   destination address unless this
   is enabled for the specific Source Address and/or the group
   Destination Address.
   
(You could use "and/or" wherever I have put "or", but in my view it's not necessary, after all, it's not "xor".)

### Section 5.2, expository paragraph needed?

Is this paragraph doing any necessary work?

   When an ICMP Parameter Problem, Code 2, message is delivered to the
   source, the source can become aware that at least one node on the
   path has failed to recognize the option.  Generating an ICMP message
   incurs additional router processing.  Reception of this message is
   not guaranteed, routers might be unable to be configured so that they
   do not generate these messages, and they are not always forwarded to
   the source.  The motivation here is to loosen the requirement to send
   an ICMPv6 Parameter Problem message when a router forwards a packet
   without processing the list of all options.

I can see how it might've been needed during working group development of the document, but if I imagine I'm an implementor reading this spec, I'm not sure what I do with it. As far as I can tell the whole thing can be condensed down to "you might not get an IMCP parameter problem if one of your options isn't recognized, but then again that was always true"... and because of "that was always true", you could leave it out without harm.

### Section 5.2.1

      The function of a Router Alert Option can result in the processing
      that this specification is proposing to eliminate, that is, to
      instruct a router to process the packet in the control plane.
      
I don't think this specification is solely proposing to protect the control plane, it's also trying to protect the forwarding plane from option lists that are too heavyweight to be processed at line rate in the fast path. (Bullets 3 and 4 in the second bullet list in Section 4.)

Fortunately, a rewrite to correct this is as simple as removing one definite article.

NEW:
      The function of a Router Alert Option can result in processing
      that this specification is proposing to eliminate, that is, to
      instruct a router to process the packet in the control plane.

### Section 5.2.2, inappropriate RFC 2119 keyword

The final paragraph of this section is the single sentence,

   The actions of the lookup table SHOULD be configurable by the
   operator of the router.

But the previous paragraph told me that said lookup table is "a possible approach". It seems weird to me to use an RFC 2119 keyword to mandate behavior specific to "a possible approach". If I were you, I'd use lowercase "should", and I would combine this paragraph with the preceding one.

### Section 6, "simple to process" isn't actionable

   *  New Hop-by-Hop options SHOULD be designed to ensure the router can
      process the options at the full forwarding rate.  That is, they
      should be simple to process (see Section 5.2).

I don't see anything in Section 5.2 that tells me how to make an option simple to process. If you think it does explain that, please help me understand how. Otherwise, I think you should remove the cross-reference.

For that matter, even with the suggested change, this bullet point makes me a little bit sad because it feels isomorphic to the famous "don't write bugs" advice. (See also RFC 9225.) But, ¯\_(ツ)_/¯ 

### Section 8, forcing packets to the slow path can also harm the control plane

   Security issues with including IPv6 Hop-by-Hop options are well known
   and have been documented in several places, including [RFC6398],
   [RFC6192], [RFC7045] and [RFC9098].  The main issue, as noted in
   Section 4, is that any mechanism that can be used to force packets
   into the router's control plane can be exploited as a Denial-of-
   Service attack on a transit router by saturating the resources needed
   for router management (routing protocols, network management
   protocols, etc.) and cause the router to fail or perform sub-
   optimally.

There is a related but not identical issue, which is that in many routers, some resources are shared between the control plane and the slow path -- you nod to this in your definition of "slow path" in Section 3. Even if packets are forced only into the slow path, but not the control plane, that can still work as a denial of service attack against the control plane. I suppose we might get into an ontological debate about what exactly "the control plane" is in this context and whether the paragraph as written already encompasses it, but I think it would be better to err on the side of completeness even if it requires a bit more verbosity. The fix I propose is simple enough, though: s/control plane/slow path or control plane/.

### Section 8, misleading bullet points

I think these two bullet points are misleading in a couple of ways:

   *  The document sets an expectation that if a packet includes a
      single Hop-by-Hop option that packet will be forwarded across the
      network path."

   *  Additional Hop-by-Hop options MAY be included, based on local
      configuration.  Nodes only process these additional Hop-by-Hop
      options if configured to do so.

The first bullet, by focusing on "a single Hop-by-Hop option", implies that if multiple options were included, the packet might not be forwarded. I think that's not right, per my understanding of the document.

The second bullet's second sentence ("only process... if") appears to be a case of "the exception proves the rule" that nodes commit to processing the first Hop-by-Hop option. But this is also not right. For that matter, it's not clear whether "nodes" in that sentence refers to destination or intermediate nodes. I have assumed the latter.

A rewrite might be,

NEW:
   *  The document sets an expectation that if a packet includes a
      Hop-by-Hop Options header that packet will be forwarded across the
      network path.

   *  A source MAY include one or more Hop-by-Hop options. Whether 
      any of these options is processed, and if so which and how many,
      is dependent on the configuration of intermediate nodes.

This document made me sad

Thank you to Behcet Sarikaya for the GENART review.

Thank you for addressing my DISCUSS feedback.

** What is the relationship between the guidance found in this document and the filtering guidance in RFC9288?

Thanks for working on this specification. Thanks for Brian Trammell for the TSVART review.

I have no issues here from transport protocol point of view, however, I am supporting Roman's discuss as I would also like to know what is classified as reasonable exception.