[bess] Roman Danyliw's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Mon, 02 October 2023 21:16 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-mvpn-evpn-aggregation-label@ietf.org, bess-chairs@ietf.org, bess@ietf.org, slitkows.ietf@gmail.com, slitkows.ietf@gmail.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <169628136408.59616.18138356708463633114@ietfa.amsl.com>
Date: Mon, 02 Oct 2023 14:16:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/1qSJRriwyKVFsSOHtZEAKGCZl3Q>
Subject: [bess] Roman Danyliw's No Objection on draft-ietf-bess-mvpn-evpn-aggregation-label-12: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-mvpn-evpn-aggregation-label-12: 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/about/groups/iesg/statements/handling-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-bess-mvpn-evpn-aggregation-label/



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

Thank you to Robert Sparks for the SECDIR review.

** Section 4.
   This document allows three methods (Section 2.2.3) of label
   allocation for MVPN [RFC6514] or EVPN [RFC7432] PEs and specifies
   corresponding signaling and procedures.

...

   None of the [RFC6514], [RFC7432], [RFC8402] and [RFC5331]
   specifications lists any security concerns related to label
   allocation methods, and this document does not introduce new security
   concerns either.

Does this imply that the label allocations/advertising methods described in
Section 2.2.3 rely on the security properties of the mechanisms described in
other documents?  If so, can this be explicitly stated?

[bess] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker