[Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 29 October 2015 21:12 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA3E1ACE43; Thu, 29 Oct 2015 14:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 T4Odqgmcj6F5; Thu, 29 Oct 2015 14:12:16 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1015B1ACE45; Thu, 29 Oct 2015 14:12:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EF6F024073C; Thu, 29 Oct 2015 14:12:12 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 822782402B7; Thu, 29 Oct 2015 14:12:12 -0700 (PDT)
To: "A. Jean Mahoney" <mahoney@nostrum.com>, General Area Review Team <gen-art@ietf.org>, draft-ietf-pce-pcep-domain-sequence.all@ietf.org
References: <5631337F.3050703@nostrum.com> <56320B67.9050309@nostrum.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <56328BAB.2000208@joelhalpern.com>
Date: Thu, 29 Oct 2015 17:12:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56320B67.9050309@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/tduD4DY0VE7CqJ7d_N2MXerRRR4>
Subject: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2015 21:12:17 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pce-pcep-domain-sequence
     Standard Representation of Domain-Sequence
Reviewer: Joel M. Halpern
Review Date: 29-October-2015
IETF LC End Date: 09-November-2015
IESG Telechat date: N/A

Summary: This draft is almost ready for publication as an experimental RFC.

Major issues:
     Given that Exclude Route Objects are not interleaved with include 
Objects, is there a restriction that Area IDs may only be excluded from 
paths within a single AS?

Minor issues:
     It seems a bit odd for an Experimental RFC to use "Standard" in its 
title.  As one possible solution, in parallel with the naming of the 
related TEAS draft, this could be "Domain Subobjects for Path 
Computation Engine Protocol."

     The procedure for updating AS number scope when observing an IP 
address at a PCE processing an IRO seems fragile as described.  Many of 
the real-time mechanisms for this are error prone.  I would recommend 
that a note be added that this construct be avoided in building IROs 
whenever possible.

Nits/editorial comments: