[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: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, 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 direction. 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 layers. 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 .
- [Teas] Martin Vigoureux's No Objection on draft-i… Martin Vigoureux
- Re: [Teas] Martin Vigoureux's No Objection on dra… Adrian Farrel
- Re: [Teas] Martin Vigoureux's No Objection on dra… Martin Vigoureux
- Re: [Teas] Martin Vigoureux's No Objection on dra… Daniele Ceccarelli
- Re: [Teas] Martin Vigoureux's No Objection on dra… Martin Vigoureux
- Re: [Teas] Martin Vigoureux's No Objection on dra… Daniele Ceccarelli
- Re: [Teas] Martin Vigoureux's No Objection on dra… Martin Vigoureux
- Re: [Teas] Martin Vigoureux's No Objection on dra… Leeyoung
- Re: [Teas] Martin Vigoureux's No Objection on dra… Leeyoung
- Re: [Teas] Martin Vigoureux's No Objection on dra… Martin Vigoureux