[tsvwg] Gen-art Telechat review: draft-ietf-tsvwg-rsvp-pcn-10

[Robert Sparks <[e-mail]>]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tsvwg-rsvp-pcn-10
Reviewer: Robert Sparks
Review Date: 2-Oct-2014
IETF LC End Date:
IESG Telechat date: 2-Oct-2014

Summary: Ready for publication as an Experimental RFC

My nits from the earlier review (below) have been addressed.

If you end up with pushback on simply using lowercase 'must' and 
'should' in your terminology session, one alternative to avoid the 
potential 2119 confusion would be to say "will" and "will usually", and 
if necessary, point to the document where the real normative statement 
lives.

RjS


_______________________________________________
On 8/21/14 10:43 PM, Robert Sparks wrote:
> 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?
>
>
>