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.