[Gen-art] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09

Robert Sparks <rjsparks@nostrum.com> Thu, 21 August 2014 20:43 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 08B7A1A8A0D; Thu, 21 Aug 2014 13:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 mpDLI8KWGZZA; Thu, 21 Aug 2014 13:43:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750051A6FAC; Thu, 21 Aug 2014 13:43:36 -0700 (PDT)
Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7LKhZbe097933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 15:43:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local
Message-ID: <53F659F7.3080106@nostrum.com>
Date: Thu, 21 Aug 2014 15:43:35 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, tsvwg@ietf.org, draft-ietf-tsvwg-rsvp-pcn.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/quXYPLnPbHsRHo-vhvUR28bWTc0
Subject: [Gen-art] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09
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: Thu, 21 Aug 2014 20:43:39 -0000

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-tsvwg-rsvp-pcn-09
Reviewer: Robert Sparks
Review Date: 21 Aug 2014
IETF LC End Date: 26 Aug 2014
IESG Telechat date: 2 Oct 2014

Summary: Ready (with nits) for publication as Experimental.

David's shepherd writeup points out that implementation and usage 
experience is desired before producing a proposed standard. Are there 
any points of concern about how this might behave (or misbehave) in a 
deployed network that such experience would inform? If so, it would be 
useful to call them out in the document.

It would be nicer if the document argued why there are no new security 
considerations introduced by the new behavior defined in this draft, 
rather than tacitly asserting that there aren't any.

The terminology section has lots of 2119 words in it. It's hard to tell 
when these have been copied from some other draft (and this is just 
restating them) vs when this draft is introducing a new requirement. 
Since a new requirement would likely be missed if it appeared only in a 
terminology section, would it be feasible to make sure anything new is 
well covered in section 3 or 4 and remove 2119 from these definitions 
altogether?

The rest of these comments are minor editorial nits:

Section 1.2, paragraph 3: "Intserv over Diffserv can operate over a 
statically provisioned Diffserv region or RSVP aware." is missing a a 
word somewhere.

Section 1.2 paragraph 4: "By using multiple aggregate reservations for 
the same PHB allows enforcement of the different preemption priorities 
within the aggregation region." doesn't parse. Should the initial "By" 
be deleted?

The definition for PCN-domain is very close to circular. Perhaps some 
words can be removed?