[OPSEC] Lars Eggert's No Objection on draft-ietf-opsec-ipv6-eh-filtering-08: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-opsec-ipv6-eh-filtering-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is mostly a personal style issue, but I find large parts of the document
hard to read, because of a myriad of very short (1-2 line) subsections, each
with their own repetitive section heading.

Section 2.3. , paragraph 7, comment:
>    We recommend that configuration options are made available to govern
>    the processing of each IPv6 EH type and each IPv6 option type.  Such
>    configuration options should include the following possible settings:

Out of curiosity, is there a reason a "strip option and forward packet" isn't
one of the options below?

Section 3.2. , paragraph 2, comment:
>    In some device architectures, IPv6 packets that contain IPv6 EHs can
>    cause the corresponding packets to be processed on the slow path, and
>    hence may be leveraged for the purpose of Denial of Service (DoS)
>    attacks [I-D.ietf-v6ops-ipv6-ehs-packet-drops] [Cisco-EH]
>    [FW-Benchmark].

Do such device architectures really still exist in 2021? The [Cisco-EH]
reference is from 2006, and the URL in [FW-Benchmark] does not seem to return
content. ([I-D.ietf-v6ops-ipv6-ehs-packet-drops] seemed to only refer to those
two references as well.)

Section 3.4.1.2. , paragraph 2, comment:
>    This EH is specified in [RFC8200].  At the time of this writing, the
>    following options have been specified for the Hop-by-Hop Options EH:

Wouldn't a pointer to the respective IANA registry suffice here, rather than a
list that is going to be inaccurate with time?
(And reading on, I see that other subsections contain similar "at the time of
this writing" lists; I would suggest replacing them all with pointers to the
respective registries.)

Document has Informational status, but uses RFC2119 keywords.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "his"; alternatives might be "they", "them", "their".

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.3.3.1. , paragraph 2, nit:
>  This option is meant to survive outside of an RPL instance. As a result, di
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 4.3.8.4. , paragraph 2, nit:
> n intermediate system can know whether or not that particular intermediate s
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Document references draft-ietf-v6ops-ipv6-ehs-packet-drops-06, but -08 is the
latest available revision.

Obsolete reference to RFC2460, obsoleted by RFC8200 (this may be on purpose).

These URLs in the document did not return content:
 *
 http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf

These URLs in the document can probably be converted to HTTPS:
 *
 http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf
 * http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml *
 http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml