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

[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.

[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.

[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)?

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]

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.

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.

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

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.

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.

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.

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?

  (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).