[Idr] Roman Danyliw's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 03 December 2020 15:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEECA3A0D6F; Thu, 3 Dec 2020 07:02:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-idr-tunnel-encaps@ietf.org, idr-chairs@ietf.org, idr@ietf.org, John Scudder <jgs@juniper.net>, aretana.ietf@gmail.com, Susan Hares <shares@ndzh.com>, shares@ndzh.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <160700777482.26979.18432434254166024114@ietfa.amsl.com>
Date: Thu, 03 Dec 2020 07:02:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/SIo1cWBauiIhwANgxvOFsyyLobw>
Subject: [Idr] Roman Danyliw's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 15:02:55 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-idr-tunnel-encaps-20: Discuss

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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Per the conversation on my original COMMENT (thanks for the quick response),
https://mailarchive.ietf.org/arch/msg/idr/hV2t6-8mq2dOvmXO-PvLuiON5o4/, I'm
escalating this item to a DISCUSS.

Section 11
However, it is intended that the Tunnel Encapsulation
attribute be used only within a well-defined scope, e.g., within a
set of Autonomous Systems that belong to a single administrative
entity.

As this applicability text should be read as a normative SHOULD, please provide
a discussion on the risks of open Internet usage in the Security Considerations.


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

Thank you to Scott Kelly for performing the SECDIR review.

** Section 1.5.  Per “Because RFC 8365 depends on RFC 5640, it is similarly
obsoleted.”, this seems inconsistent with the meta-data header in the document
(as RFC8365 isn’t obsoleted).

** (original COMMENT, see DISCUSS above) Section 11.  Please use normative
language on the applicability text restricting use to a single administrative
domain.

OLD
However, it is intended that the Tunnel Encapsulation
   attribute be used only within a well-defined scope, e.g., within a
   set of Autonomous Systems that belong to a single administrative
   entity.

NEW (or something like this)

However, the Tunnel Encapsulation attribute MUST only be used within a
well-defined scope such as a set of Autonomous Systems that belong to a single
administrative entity.

** Section 12.  Typo. s/tunnelling/tunneling/

** Section 15.  Clarifying text
OLD
"hijacking" of traffic (insertion of
   an undesired node in the path)

NEW
"hijacking" of traffic (insertion of an undesired node in the path allowing for
inspection or modification of traffic, or avoidance of security controls)