[mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Sun, 28 November 2021 02:51 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-lsp-ping-ospfv3-codepoint@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org, Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, draft-ietf-mpls-lsp-ping-ospfv3-codepoint@ietf.org, loa@pi.nu
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163806787751.1266.5673727732703418159@ietfa.amsl.com>
Date: Sat, 27 Nov 2021 18:51:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Y8VsCQE7GA-QuHGnVlOGAx-pOrE>
Subject: [mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ospfv3-codepoint/



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

Section 4

   When the protocol field in the received Segment ID sub-TLV Type 35
   and Type 36 is OSPF (value 1), the responder MAY treat the protocol
   value as "Any IGP Protocol" (value 0) according to step 4a of
   Section 7.4 of [RFC8287].  This allows the responder to support
   legacy implementations that use value 1 to indicate OSPFv3.

Is there any guidance to give on how long we expect there to be need for
the "treat as any" behavior to be implemented?  ("No" is a valid
answer.)

Section 6

   This document updates [RFC8287], by specifying that the "OSPF" code
   points SHOULD be used only for OSPFv2.

Why do we use SHOULD here but say in §4 that the initiator "MUST NOT set
[...] as OSPF (value 1)"?

Section 7

I have a mild preference for noting in the I-D when an early allocation
is being confirmed, but since it doesn't end up in the final RFC it
probably doesn't really matter.

Section 8

Pedantically, this document does encourage you ("MAY") to treat the
OSPV(v2) codepoint as "any protocol" in a couple of scenarios, which
would in principle open up a risk of an attacker causing you to use
(e.g.) IS-IS when OSPF was intended.  Is that a significant new risk?
Probably not.  But it may be enough to move away from saying "does not
introduce any additional security considerations".  "no significant new
security considerations" would be unobjectionable to me.

NITS

Section 6

   the Protocol field of the Segment ID sub-TLV.  Section 6 of [RFC8287]
   defines the code point for OSPF to be used in the Protocol field of
   the DDMAP TLV.

I'd suggest expanding "DDMAP" here.

[mpls] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker