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

Alvaro Retana via Datatracker <noreply@ietf.org> Tue, 13 July 2021 10:55 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsec-ipv6-eh-filtering@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, evyncke@cisco.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <162617372562.1517.9358558617176628464@ietfa.amsl.com>
Date: Tue, 13 Jul 2021 03:55:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/F4Vo1ZmTk9CyMdVYVfRfkaOcR7k>
Subject: [OPSEC] Alvaro Retana's No Objection on draft-ietf-opsec-ipv6-eh-filtering-08: (with COMMENT)

Alvaro Retana 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:
----------------------------------------------------------------------

(1) §2.3: Using normative language in listing the requirements from rfc7045 is
not appropriate without quotes, to make it clear where the rfc2119 keywords
come from.  Also, the text is not exactly what rfc7045 says; for example, the
last bullet uses "should" while the original text says "SHOULD".

(2) [nit] §3.4.1.2: The list of currently-defined options seems unnecessary
given that no type-specific recommendation is made.  [Similar comments apply to
other lists.]

(3) §3.4.1.5: "...for obvious reasons, RPL...[RFC6550] routers must not discard
packets based on the presence of an IPv6 Hop-by-Hop Options EH."  The reason
may not be obvious to everyone -- also, rfc6553 may be a better reference in
this case.

(4) §3.4.2.3/§3.4.2.4: Not all routing headers receive the same treatment.  For
example, RHT4 is mentioned when talking about both the implications and impact,
while RHT3 is not mentioned at all.  Consistent treatment would be nice.

(5) [nit] §4.3.3.5:

   Intermediate systems should discard packets that contain this option.
   An operator should permit this option only in specific scenarios in
   which support for IPv6 jumbograms is desired.

The advice in this case would be complete if only the second sentence is
included.

(6) §4.3.4.4: s/(e.g. at an ISP)/outside the RPL instance

(7) §4.3.5.4: "This option is meant to survive outside of an RPL instance."

The option can survive outside the LLN, but as rfc9008 says, the "intention was
and remains that the Hop-by-Hop Options header with a RPL Option should be
confined within the RPL domain".

Suggestion>  This option can survive outside of an RPL instance.

[OPSEC] Alvaro Retana's No Objection on draft-iet… Alvaro Retana via Datatracker