Last Call Review of draft-ietf-pcn-cl-edge-behaviour-
review-ietf-pcn-cl-edge-behaviour-genart-lc-carpenter-2012-01-01-00

Please see attached review.


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-pcn-cl-edge-behaviour-11.txt
Reviewer: Brian Carpenter
Review Date: 2012-01-02
IETF LC End Date: 2012-01-13
IESG Telechat date: 

Summary:  Almost ready
--------

Comments:
---------

I think most of my comments also apply to draft-ietf-pcn-sm-edge-behaviour.
Conversely, I agree with Joel's comments, including that Experimental would be
a suitable status.

As a co-author of RFC 3086, I claim some expert knowledge of this area. I haven't
found any serious technical issues in the draft and it does adhere to the relevant
parts of the diffserv architecture. I reserve judgment whether PCN will actually
work in the field at very large scale; it's an experiment that needs to be tried.

Minor issues:
-------------

There are several instances of the phrase "notify management" as the action to
be taken when certain failures occur. This doesn't seem satisfactory to me;
they seem to be points where the state machine has an undefined arc.
The Internet is supposed to keep on truckin' whatever happens - that's why
the default QoS behaviour has always been to revert to Best Effort service
when all else fails. Maybe the PCN architecture sheds more light on what 
happens when PCN hits a failure mode? Does traffic that is rejected by
PCN admission control revert to Best Effort? That is consistent with
the diffserv philosophy.

In section 5.2. "Management Considerations":

   o  PRI initially set to 115, representing a Facility value of (14)
      "log alert" and a Severity level of (3) "Error Condition".  

and some other references to PRI. The acronym is not defined. What is it,
and do the suggested values come from an existing IANA registry, or are
they newly defined here?

Editorial:
----------

The Introduction mentions:

   [RFC EDITOR'S NOTE: you may choose to delete the following paragraph
   and the "[CL-specific]" tags throughout this document when publishing
   it, since they are present primarily to aid reviewers.  RFCyyyy is
   the published version of draft-ietf-pcn-sm-edge-behaviour.]

   A companion document [RFCyyyy] specifies the Single Marking (SM) PCN-
   boundary-node behaviour.  This document and [RFCyyyy] have a great
   deal of text in common.  To simplify the task of the reader, the text
   in the present document that is specific to the CL PCN-boundary-node
   behaviour is preceded by the phrase: "[CL-specific]".  A similar
   distinction for SM-specific text is made in [RFCyyyy].

My recommendation is to keep the second paragraph and the [CL-specific] tags. 
They will help future readers and implementors. Of course, the same
decision should be made for draft-ietf-pcn-sm-edge-behaviour.