[Teas] Paul Wouters' No Objection on draft-ietf-teas-enhanced-vpn-19: (with COMMENT)

Paul Wouters via Datatracker <noreply@ietf.org> Thu, 13 June 2024 13:57 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B36C14F5ED; Thu, 13 Jun 2024 06:57:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171828702315.48549.7224120484626975424@ietfa.amsl.com>
Date: Thu, 13 Jun 2024 06:57:03 -0700
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-teas-enhanced-vpn@ietf.org, teas-chairs@ietf.org, teas@ietf.org, lberger@labn.net
X-Mailman-Version: 3.3.9rc4
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Subject: [Teas] Paul Wouters' No Objection on draft-ietf-teas-enhanced-vpn-19: (with COMMENT)
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/DligTh-QD1WTG7RBA9Bg1eJq9mE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Paul Wouters has entered the following ballot position for
draft-ietf-teas-enhanced-vpn-19: 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:


"Enhanced VPNS" can be easily confused for EVPN / Ethernet VPN ? The
term is also sometimes capitalized and sometimes not, making it look
like a formal term and sometimes like an informal description. Why
not avoid using the word enhanced and call it "NRP VPN" ?

       [RFC9543] discusses the general framework, components, and interfaces for
       requesting and operating network slices using IETF technologies. These network
       slices may be referred to as RFC 9543 Network Slices, but in this document
       (which is solely about IETF technologies) we simply use the term "network
       slice" to refer to this concept.

There was a long discussion with the IESG for RFC9543 to not confuse the technology
with 5G network slices. Creating this "alias" here of course counters that whole

        While an enhanced VPN service may be sold as offering encryption
        and other security features as part of the service, customers
        would be well advised to take responsibility for their own
        security requirements themselves possibly by encrypting traffic
        before handing it off to the service provider.

This is true of all VPNs, and not really a security consideration for NRP VPNs ?

        The privacy of enhanced VPN service customers must be
        preserved. It should not be possible for one customer to discover
        the existence of another customer, nor should the sites that
        are members of an enhanced VPN be externally visible.

Same here?