[RTG-DIR] RtgDir review: draft-ietf-teas-pce-central-control-03

Thomas Morin <thomas.morin@orange.com> Mon, 10 July 2017 14:50 UTC

Return-Path: <thomas.morin@orange.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E490C127B57; Mon, 10 Jul 2017 07:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.535
X-Spam-Level:
X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yU4qpqmpRpo; Mon, 10 Jul 2017 07:50:33 -0700 (PDT)
Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7B30C124B0A; Mon, 10 Jul 2017 07:50:30 -0700 (PDT)
Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1923A5D84F2; Mon, 10 Jul 2017 16:50:29 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 009305D838B; Mon, 10 Jul 2017 16:50:29 +0200 (CEST)
Received: from [10.193.71.183] (10.193.71.183) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Mon, 10 Jul 2017 16:50:28 +0200
From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, draft-ietf-teas-pce-central-control.all@ietf.org, teas@ietf.org
Message-ID: <f36e9844-729e-4887-4673-2452e359cbd3@orange.com>
Date: Mon, 10 Jul 2017 16:50:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/V4Q5v95T2nAiZDI6vYg5d7ZgMmc>
Subject: [RTG-DIR] RtgDir review: draft-ietf-teas-pce-central-control-03
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jul 2017 14:50:38 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-teas-pce-central-control-03
Reviewer: Thomas Morin
Review Date: 2017-07-10
IETF LC End Date: ?
Intended Status: Informational

Summary:

     No issues found. This document is ready for publication.

Comments:

     Saying that the draft is well written would be an understatement: 
it reads like a fairy tale.  And a nicely illustrated one.

     Beyond the (barely) private joke, despite the document being 
overall fairly honest in detailing the conditions under which the PCE 
architecture and PCEP could be generically applicable to central 
control, I'm under the impression that the document could exercise a bit 
more criticism on this idea in some places. In particular, section 3.2.3 
on service delivery and the start of section 4, may lead the reader into 
believing that it it may actually be easy to adapt PCEP for this use 
case ("only realtively minor changes"), even though the document does 
not provide rationale to support that this would be easier than, for 
instance, completing the Netconf/YANG framework for the same purpose. 
That is to say, the document would be more interesting in this area, if 
it was discussing whether or not actually choosing to extend PCEP for 
this purpose is a direction to favor in particular.

Nits:

     First paragraph of section 2.1.1 ends with 'control "domains." ' 
where I would have expected 'control "domains".', but this is possibly 
just me being not aware of a typography rule.