Skip to main content

Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation
draft-ietf-pcn-cl-edge-behaviour-15

Revision differences

Document history

Date Rev. By Action
2012-05-13
15 Brian Carpenter Request for Telechat review by GENART Completed. Reviewer: Brian Carpenter.
2012-05-11
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-05-11
15 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2012-05-11
15 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-05-11
15 Tom Taylor New version available: draft-ietf-pcn-cl-edge-behaviour-15.txt
2012-05-07
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-05-07
14 (System) IANA Action state changed to In Progress from Waiting on ADs
2012-05-04
14 (System) IANA Action state changed to Waiting on ADs from Waiting on Authors
2012-05-03
14 (System) IANA Action state changed to Waiting on Authors from Waiting on ADs
2012-04-25
14 (System) IANA Action state changed to Waiting on ADs from In Progress
2012-04-24
14 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2012-04-23
14 (System) IANA Action state changed to In Progress
2012-04-23
14 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-04-23
14 Amy Vezza IESG has approved the document
2012-04-23
14 Amy Vezza Closed "Approve" ballot
2012-04-23
14 Amy Vezza Ballot approval text was generated
2012-04-23
14 Amy Vezza Ballot writeup was changed
2012-04-23
14 Amy Vezza Ballot writeup was changed
2012-04-23
14 Martin Stiemerling State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2012-04-20
14 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2012-04-05
14 Tom Taylor New version available: draft-ietf-pcn-cl-edge-behaviour-14.txt
2012-03-29
13 Martin Stiemerling Responsible AD changed to Martin Stiemerling from David Harrington
2012-03-22
13 Cindy Morgan New version available: draft-ietf-pcn-cl-edge-behaviour-13.txt
2012-03-19
12 David Harrington Ballot approval text was generated
2012-03-19
12 David Harrington Ballot approval text was generated
2012-03-15
12 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2012-03-15
12 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-03-15
12 Pete Resnick [Ballot comment]
See -sm document.
2012-03-15
12 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-03-15
12 Sean Turner
[Ballot comment]
Same comments as draft-ietf-pcn-sm-edge-behavior.

s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term "decision point" explicitly, I think …
[Ballot comment]
Same comments as draft-ietf-pcn-sm-edge-behavior.

s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term "decision point" explicitly, I think that adding some text along the lines of "The decision point is considered to be part of a PCN-node; therefore, the decision point is considered to be trusted for truthful decisions."  This makes it clear that s6.3.1 of RFC 5559 applies.

s4.2.1: I find it a little odd that you say you're paraphrasing two sections but there's 2119 language in this draft where there was none in RFC 5559.  Granted it's mostly MAY this and MAY that so it's not that big of a deal, but there is a MUST and a NOT RECOMMENDED.  Are you really paraphrasing the text from RFC 5559 in that case?

s1.1: Need to add NOT RECOMMENDED to the key words.
2012-03-15
12 Sean Turner Ballot comment text updated for Sean Turner
2012-03-15
12 Sean Turner
[Ballot comment]
Same comments as draft-ietf-pcn-sm-edge-behavior.

s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term
"decision point" explicitly, I think …
[Ballot comment]
Same comments as draft-ietf-pcn-sm-edge-behavior.

s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term
"decision point" explicitly, I think that adding some text along the lines of
"The decision point is considered to be part of a PCN-node; therefore, the
decision point is considered to be trusted for truthful decisions."  This makes
it clear that s6.3.1 of RFC 5559 applies.

s4.2.1: I find it a little odd that you say you're paraphrasing two sections but
there's 2119 language in this draft where there was none in RFC 5559.  Granted
it's mostly MAY this and MAY that so it's not that big of a deal, but there is a
MUST and a NOT RECOMMENDED.  Are you really paraphrasing the text from RFC 5559
in that case?

s1.1: Need to add NOT RECOMMENDED to the key words.
2012-03-15
12 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-03-15
12 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-03-15
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2012-03-14
12 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-03-13
12 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-03-13
12 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-03-12
12 David Harrington Intended Status changed to Experimental from Informational
2012-03-11
12 Stephen Farrell [Ballot comment]

[SM-Specific] please see my comment on the other one of these...
2012-03-11
12 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2012-03-09
12 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2012-03-09
12 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2012-03-09
12 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2012-03-08
12 Peter Saint-Andre
[Ballot comment]
This document contains quite a bit of requirements terminology. Are we sure that Informational is appropriate? Did the WG consider making this a …
[Ballot comment]
This document contains quite a bit of requirements terminology. Are we sure that Informational is appropriate? Did the WG consider making this a standards-track Applicability Statement (Section 3.2 of RFC 2026)?
2012-03-08
12 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded for Peter Saint-Andre
2012-03-06
12 David Harrington State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2012-03-06
12 David Harrington Placed on agenda for telechat - 2012-03-15
2012-03-06
12 David Harrington Ballot has been issued
2012-03-06
12 David Harrington [Ballot Position Update] New position, Yes, has been recorded for David Harrington
2012-03-06
12 David Harrington Ballot writeup was changed
2012-03-06
12 David Harrington Created "Approve" ballot
2012-02-22
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2012-02-22
12 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-12.txt
2012-01-13
12 David Harrington State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
IETF LC comments from Joel Halpern need to be addressed.
2012-01-13
12 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2012-01-06
12 Amanda Baber
IANA understands that, upon approval of this document, a single IANA
action will be required.

In the Syslog Structured Data ID Values registry at

http://www.iana.org/assignments/syslog-parameters …
IANA understands that, upon approval of this document, a single IANA
action will be required.

In the Syslog Structured Data ID Values registry at

http://www.iana.org/assignments/syslog-parameters

the following values will be added:

Structured Data ID Structured Data Parameter Required or Optional Reference
------------------ ----------------- -------------------- ---------
PCNNode OPTIONAL [RFC-to-be]
ID MANDATORY [RFC-to-be]
Rtyp MANDATORY [RFC-to-be]
PCNTerm OPTIONAL [RFC-to-be]
IngrID CONDITIONAL [RFC-to-be]
EgrID MANDATORY [RFC-to-be]
TermRate MANDATORY [RFC-to-be]
FCnt MANDATORY [RFC-to-be]
2012-01-01
12 Brian Carpenter Request for Last Call review by GENART Completed. Reviewer: Brian Carpenter.
2011-12-30
12 Mary Barnes Request for Last Call review by GENART is assigned to Brian Carpenter
2011-12-30
12 Mary Barnes Request for Last Call review by GENART is assigned to Brian Carpenter
2011-12-23
12 Amy Vezza Last call sent
2011-12-23
12 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of
  Operation'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Pre-congestion notification (PCN) is a means for protecting the
  quality of service for inelastic traffic admitted to a Diffserv
  domain.  The overall PCN architecture is described in RFC 5559.  This
  memo is one of a series describing possible boundary node behaviours
  for a PCN-domain.  The behaviour described here is that for a form of
  measurement-based load control using three PCN marking states, not-
  marked, threshold-marked, and excess-traffic-marked.  This behaviour
  is known informally as the Controlled Load (CL) PCN-boundary-node
  behaviour.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/


No IPR declarations have been submitted directly on this I-D.


2011-12-23
12 David Harrington Last Call was requested
2011-12-23
12 David Harrington State changed to Last Call Requested from In Last Call.
2011-12-23
12 David Harrington Last Call text changed
2011-12-23
12 David Harrington Ballot writeup text changed
2011-12-23
12 David Harrington Ballot writeup text changed
2011-12-23
12 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of
  Operation'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Pre-congestion notification (PCN) is a means for protecting the
  quality of service for inelastic traffic admitted to a Diffserv
  domain.  The overall PCN architecture is described in RFC 5559.  This
  memo is one of a series describing possible boundary node behaviours
  for a PCN-domain.  The behaviour described here is that for a form of
  measurement-based load control using three PCN marking states, not-
  marked, threshold-marked, and excess-traffic-marked.  This behaviour
  is known informally as the Controlled Load (CL) PCN-boundary-node
  behaviour.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/


No IPR declarations have been submitted directly on this I-D.


2011-12-23
12 David Harrington Ballot writeup text changed
2011-12-23
12 David Harrington Last Call text changed
2011-12-23
12 David Harrington Last Call was requested
2011-12-23
12 David Harrington State changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup.
2011-12-23
12 David Harrington Last Call text changed
2011-12-19
11 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-11.txt
2011-10-23
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-10-23
10 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-10.txt
2011-08-30
12 David Harrington
State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup.
discussion of signaling protocol needed. Please also address the editorial …
State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup.
discussion of signaling protocol needed. Please also address the editorial issues raised by me on 5-17
2011-06-22
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-06-22
09 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-09.txt
2011-06-21
12 David Harrington
State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
The IETF Last Call raised issues with the interoperability issues of …
State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
The IETF Last Call raised issues with the interoperability issues of not having a specified message format, and not having operations and management considerations explaining how information is reported in an interoperable manner, or which protocols are mandatory-to-implement or at least recommended. These issues must be addressed.  Other comments that were  raised during last call should also be addressed while the document is under edit.
2011-06-10
12 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-08
12 Amanda Baber [Note]: 'Steven Blake (slblake@petri-meat.com> is the document shepherd)' added by Amanda Baber
2011-06-08
12 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-06-03
12 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Love Astrand.
2011-06-01
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Love Astrand
2011-06-01
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Love Astrand
2011-06-01
12 Samuel Weiler Assignment of request for Last Call review by SECDIR to Dan Harkins was rejected
2011-05-31
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Dan Harkins
2011-05-31
12 Samuel Weiler Request for Last Call review by SECDIR is assigned to Dan Harkins
2011-05-27
12 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of
  Operation'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


Pre-congestion notification (PCN) is a means for protecting the
quality of service for inelastic traffic admitted to a Diffserv
domain.  The overall PCN architecture is described in RFC 5559.  This
memo is one of a series describing possible boundary node behaviours
for a PCN-domain.  The behaviour described here is that for a form of
measurement-based load control using three PCN marking states, not-
marked, threshold-marked, and excess-traffic-marked.  This behaviour
is known informally as the Controlled Load (CL) PCN-boundary-node
behaviour.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/


No IPR declarations have been submitted directly on this I-D.


2011-05-27
12 David Harrington Last Call was requested
2011-05-27
12 David Harrington State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-05-27
12 David Harrington Last Call text changed
2011-05-27
12 (System) Ballot writeup text was added
2011-05-27
12 (System) Last call text was added
2011-05-27
12 (System) Ballot approval text was added
2011-05-17
12 David Harrington
AD Followup for pcn-cl and pcn-sm documents.

---
I reviewed CL -08- and found only minor editorial problems

1) In the last paragraph of section …
AD Followup for pcn-cl and pcn-sm documents.

---
I reviewed CL -08- and found only minor editorial problems

1) In the last paragraph of section 3, the paragraph about T-fail, the second sentence starts with "As for T-maxsuppress," which seems out of place.

Please correct these as part of responding to IETF Last Call comments. No need to publish a revision before IETF LC.

---
I compared the common text in CL -08- and SM -05-.
I just want to verify these differences are deliberate:

1) in section 2, the reference rate is set to PCN-supportable for CL, but PCN-admissible for SM.

2) in 3.2.1, the ETM-rate for CL is marked with the EXP codepoint, but ETM-rate for CL is marked with the PM codepoint.
(while the ThM rate for CL i smarked with the PM codepoint)

3) in 5.3, termination SHOULD happen for cl, but termination should happen for SM. (note case)

4) in 5.4, paramaters for each interior node, reference rate "on each link" for CL, and 'on each inward link" for SM

Please verify these were deliberate.
2011-05-03
12 David Harrington State changed to AD Evaluation::AD Followup from AD Evaluation::Revised ID Needed.
2011-04-01
12 David Harrington State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
2010-12-15
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-15
08 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-08.txt
2010-12-06
12 David Harrington State changed to AD Evaluation::Revised ID Needed from Publication Requested.
2010-12-06
12 David Harrington
AD Evaluation:

Because this document has so much common text with the SM document, almost all the AD Review comments for the SM document apply …
AD Evaluation:

Because this document has so much common text with the SM document, almost all the AD Review comments for the SM document apply to CL as well. Please incorporate those comments into this review.

A few comments came to mind after sending the SM review, that apply to both; I added parenthesis to indictae it applies to both).

1) in section 2, reference is made to the "possible extension" [ID.PCN3in1].
I recommend against referencing "possible extension" documents.

2) "These allowable transitions are specified here" - usually specified implies a normative specification. I suggest rewording with less normative-like wording.

3) in 3.2.3, the calculation for CLE uses either the latest or the previous interval in its caculations. Niether SM nor CL explains why it is acceptable to use either interval. Is this explained somewhere? How does this affect interoperability? (also applies to SM)

4) in 3.3.2, the DP MUST request an estimate of pcn-sent-rate; is there a specific protocol that must/should be used to do this (assuming they are not co-located)? If not, how is this request/response done in a vendor-interoperable manner?

5) in 3.3.2, last paragraph, the list must be ETM-marked flows, right? It doesn't say that.

6) in 3.3., an alarm should be raised to management. is there are standardized approach to raising the alarm? If not, how does this affect interoperability. Most notably, if two nodes form different vendors raise an alarm using different protocols, how will the management system correlate the alarms? If two implementations use SNMP to raise the alarms, should they use consistent OIDs to identify the problem? or consistent syslog SDEs? or consistent ipfix IEs? Should the WG standardize the information models, and possibly data models and protocols, for reporting such alarms?

7) in 5.2, it is asserted that [ID.PCN3in1] specifies the behavior; but 2.2 mentions this as a "possible extension". If PCN3in1 is not STDS track, then i think this text in 5.2 could be problematic. But I suspect that 3086 expects a stable specification.

I have not worked with the 3086 template before. Is a reference to a number of RFCs, without any discussion of their details really sufficient? It doesn't sounce like that meets the description from 3086:

  This section specifies the rules or guidelines to create this PDB,
  each distinguished with "may", "must" and "should." The technical
  specification must list the classification and traffic conditioning
  required (if any) and the PHB (or PHBs) to be used with any
  additional requirements on their configuration beyond that contained
  in RFCs.  Classification can reflect the results of an admission
  control process.  Traffic conditioning may include marking, traffic
  shaping, and policing.  A Service Provisioning Policy might be used
  to describe the technical specification of a particular PDB.

8) in 5.7, the reader is referred to "the applicable specifications"; can we identify the applicable specifications?

2010-10-21
12 Cindy Morgan
  (1.a) Who is the Document Shepherd for this document?

>      Steven Blake, PCN co-chair
 
        Has the
  …
  (1.a) Who is the Document Shepherd for this document?

>      Steven Blake, PCN co-chair
 
        Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

>      Yes & yes.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members?
       
>      WG members - Yes
       
        Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

>      No

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

>      No

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.
       
>      No       
       
        In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.
       
>      Not applicable
       
        Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

>      No

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

>      The primary working group contributors have all indicated
>      approval for the document.  All comments brought up during
>      WGLC were satisfactorily addressed.  There are no vocal dissenters.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

>      No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

>      The document passes ID-nits with two comments:
>
>      1) The document date (September 4, 2010) is 47 days in the past. 
>          Is this intentional?  [Yes; blame the shepherd's forgetfullness].
>
>      2) No information found for draft-SM-edge-behaviour - is the name
>          correct?  [This reference should be replaced by
>          draft-ietf-pcn-sm-edge-behaviour-04, which is simultaneously
>          being submitted to the IESG].

  (1.h) Has the document split its references into normative and
        informative?
       
>      Yes
       
        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

>      All normative references in the document are RFCs.  However,
>      the shepherd questions whether the reference to 
>      draft-ietf-pcn-3-in-1-encoding should be normative.  That draft
>      has not advanced to WGLC yet.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?
       
>      An IANA Considerations section exists, but no requests are
>      made to IANA.
       
        If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

>      Not applicable

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

>      Not applicable

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

>      This document describes a possible boundary node behaviour
>      for a PCN-domain (as defined in RFC 5559), known informally as
>      the Controlled Load (CL) PCN-boundary-node behaviour.
>      The behaviour described here is a form of measurement-based
>      load control using three PCN marking states: not-marked,
>      threshold-marked, and excess-traffic-marked.

    Working Group Summary

>      The document was subject to thorough review by the PCN working
>      group, and strong consensus for publication was reached.

    Document Quality

>      The document was reviewed by the document shephard (Steven Blake).
2010-10-21
12 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2010-10-21
12 Cindy Morgan [Note]: 'Steven Blake (slblake@petri-meat.com> is the document shepherd)' added by Cindy Morgan
2010-09-04
07 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-07.txt
2010-06-28
06 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-06.txt
2010-06-26
05 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-05.txt
2010-06-22
04 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-04.txt
2010-06-22
03 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-03.txt
2010-03-08
02 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-02.txt
2009-10-27
01 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-01.txt
2009-07-06
00 (System) New version available: draft-ietf-pcn-cl-edge-behaviour-00.txt