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

Martin Vigoureux <martin.vigoureux@nokia.com> Thu, 24 May 2018 08:56 UTC

Return-Path: <martin.vigoureux@nokia.com>
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 22AA912D969; Thu, 24 May 2018 01:56:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Vigoureux <martin.vigoureux@nokia.com>
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: <152715220506.30129.5178063481055865022.idtracker@ietfa.amsl.com>
Date: Thu, 24 May 2018 01:56:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/40gnDaHOTyVW_DbpoLeCAUO0KkY>
Subject: [Teas] Martin Vigoureux'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: Thu, 24 May 2018 08:56:45 -0000

Martin Vigoureux 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:



thank you for this document. I have few questions for clarification:

* I'm not sure to understand your definition of Domain. You say:
Specifically within this document we mean a part of an operator's network that
is under common management. I'm not sure to understand what common means. 
Also, you add a sentence after that but it didn't help me, in fact it confused
me further. Is it the managed entities which have something in common or is
that the managing entities which have something in common? In the latter case
what would be the common thing?

On that matter, I would suggest to capitalise the first letter of all the
occurrences of domain which correspond to this definition (with the hope that
all of them do).

Fig. 1 shows the Customer in relation with the Service Provider but Fig. 2
shows a boundary between Customer and Network Operator. Are the NO and SP
merged in Fig. 2?

You say:
   The PNC functions can be implemented as part of an SDN domain
   controller, a Network Management System (NMS), an Element Management
   System (EMS), an active PCE-based controller [Centralized] or any
   other means to dynamically control a set of nodes and that is
   implementing an NBI compliant with ACTN specification.
I have few comments:
which ACTN specification are you referring to ?
Usually when I read "comply with a specification", I expect to read a
MUST/SHOULD in the same sentence. I can understand that you don't want to put a
compliance requirement, but then you might want to use another word than
"compliant". NBI is not defined/expanded anywhere in the doc. In fact it's the
only place where it appears. And in fact seeing it here while Fig. 2 talks
about SBI only makes the reader uncertain. One way out of this would be to make
it appear on Fig 2. because it's just the same interface, seen from the other

You say:
   A PNC domain includes all the resources under the control of a
   single PNC.  It can be composed of different routing domains and
   administrative domains, and the resources may come from different
Is that consistent with the definition of Domain? More precisely, is that
consistent with the last sentence of the Domain definition which says:
   Network elements will often be grouped into domains based on
   technology types, vendor profiles, and geographic proximity.

4.1. MDSC Hierarchy
Can there be more than two levels in the MDSC hierarchy? In other words, can an
MDSC-L for an MDSC-H be itself an MDSC-H for an MDSC-L? As a side note, since I
made the mistake while writing this, you have two occurrences of MSDC (instead
of MDSC) in the doc .