[Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 23 May 2018 16:07 UTC

Return-Path: <kaduk@mit.edu>
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 7A373127137; Wed, 23 May 2018 09:07:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-teas-actn-framework@ietf.org, Vishnu Beeram <vbeeram@juniper.net>, teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152709164646.27121.4769234793573944203.idtracker@ietfa.amsl.com>
Date: Wed, 23 May 2018 09:07:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/AeBr103TjLILDEybYn_7Zuflzoc>
Subject: [Teas] Benjamin Kaduk's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 16:07:27 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-teas-actn-framework-14: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/



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

Thanks for the clear and easy-to-follow document!

I do have a few minor comments, below.


Section 3

Please expand OSS and NMS on first usage.

Section 3.2

   [...] The two functions of the MDSC,
   namely, multi-domain coordination and virtualization/abstraction are
   referred to as network-related functions while the other two
   functions, namely, customer mapping/translation and virtual service
   coordination are referred to as service-related functions.

Starting out with "The two" implies that there are no others, which
is contradicted by "the other two" later.  So, I'd suggest just
starting with "Two functions of the MDSC ...".

Section 3.3

Please expand NBI (which appears to only be used once in the
document).

Section 5.3.2

It seems pretty likely that allowing repeated path computation
requests (with different parameters) would allow a malicious MDSC to
learn a fair amount of information about the topology that the PNC
is attempting to abstract away.  This is probably not a huge deal,
though.

Section 8.3

   A key objective of the MDSC is to support the customer's expression
   of the application connectivity request via its CNC as set of
   desired business needs, therefore policy will play an important
   role.

nit: "as a set of"

   Once authorized, the virtual network service will be instantiated
   via the CNC-MDSC Interface (CMI), it will reflect the customer
   application and connectivity requirements, and specific service
   transport needs.

nit: this is a comma splice; I'd change the comma before "it" to
either a semicolon or a period.  (There's a similar issue in the
following sentence, too.)

Section 9.2

Perhaps we should say something about configuring trust anchors for the PKI,
e.g., using a smaller set of trusted CAs than in the Web PKI.