[Gen-art] Fwd: Gen-art last call review: draft-ietf-pce-vendor-constraints-11
Robert Sparks <rjsparks@nostrum.com> Tue, 26 November 2013 21:08 UTC
Return-Path: <rjsparks@nostrum.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 7A9811AE02B for <gen-art@ietfa.amsl.com>; Tue, 26 Nov 2013 13:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level:
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=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 qG8MhxUTDyR1 for <gen-art@ietfa.amsl.com>; Tue, 26 Nov 2013 13:08:15 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 406851AE021 for <gen-art@ietf.org>; Tue, 26 Nov 2013 13:08:15 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAQL8Exg097083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for <gen-art@ietf.org>; Tue, 26 Nov 2013 15:08:14 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52950DBE.7060303@nostrum.com>
Date: Tue, 26 Nov 2013 15:08:14 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>
References: <52950B49.4040209@nostrum.com>
In-Reply-To: <52950B49.4040209@nostrum.com>
X-Forwarded-Message-Id: <52950B49.4040209@nostrum.com>
Content-Type: multipart/alternative; boundary="------------080201070002020008020609"
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Subject: [Gen-art] Fwd: Gen-art last call review: draft-ietf-pce-vendor-constraints-11
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: <http://www.ietf.org/mail-archive/web/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: Tue, 26 Nov 2013 21:08:17 -0000
missed copying gen-art -------- Original Message -------- Subject: Gen-art last call review: draft-ietf-pce-vendor-constraints-11 Date: Tue, 26 Nov 2013 14:57:45 -0600 From: Robert Sparks <rjsparks@nostrum.com> To: pce@ietf.org, draft-ietf-pce-vendor-constraints@tools.ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pce-vendor-constraints-11 Reviewer: Robert Sparks Review Date: 26 Nov 2013 IETF LC End Date: 9 Dec 2013 IESG Telechat date: not yet scheduled Summary: Ready (but I have a couple of comments for consideration) Given a quick scan of the list history for this document, I'm surprised there's not more discussion about the potential for creating islands of non-interoperable equipment, and some recommendation for when to define and how to deploy a standard version of a constraint when a common thing is found among vendor specific variants of the constraint (are there implications if an element include both the standard and vendor specific variants?) This is probably bigger than this document, and take it for what it's worth, but the practice of relisting the definition of <svec-list> when you add objects doesn't seem to be working well. For instance, had XRO or GC been defined later, you're probably ok with them being used with these objects too, right? As it is, I'm having a hard time seeing the value in redefining the grammar this way each time you add a new thing. It leads to odd artifacts like _this_ document not providing a good reference to what XRO and GC are (you have to chase through the registry, or look at 5557 or 5521, neither of which are referenced here.
- [Gen-art] Fwd: Gen-art last call review: draft-ie… Robert Sparks
- [Gen-art] Gen-art Telechat review: draft-ietf-pce… Robert Sparks
- Re: [Gen-art] Gen-art Telechat review: draft-ietf… Robert Sparks
- Re: [Gen-art] Gen-art Telechat review: draft-ietf… Jari Arkko