Baseline Encoding and Transport of Pre-Congestion Information
draft-ietf-pcn-baseline-encoding-07

[Ballot discuss]
Section 4:

" o  Any packet that is not-PCN but which shares the same Diffserv
      codepoint as PCN-enabled traffic MUST have its ECN field set to
      00."

I agree that you must do something here. However, isn't what to do depending on the incomming ECN semantics? IF it is RFC 3168 resetting the ECN does not appear to be correct action. Instead other actions are need.

I think a reformulation is needed, saying that not-PCN packets MUST NOT be forwarded within the PCN domain with the PCN-enabled DSCP and with ECN field values other than 00. Instead some other action must be taken. I don't think this document can mandate the erasing of ECN marking ECT or CE on incoming packets. Instead some other action must be taken.

[Ballot discuss]
Based on the discussion that followed Gen-ART-Review by Spencer
  Dawkins posted on 21-Aug-2009, I expected an RFC Editor note to
  resolve the comment about "Outermost IP".

[Ballot comment]
Well-written and clear. Thank you.

It might be over-cooking the text, but I would welcome additions to
section 6 that clarify that the edges of the PCN domain are assumed to
be hard. That is, it is a prerequisite of operating these PCN procedures
that ECN packets cannot leak into the PCEN domain, and that PCN packets
cannot excape. (Yes, I know this is implicit and explicit in various
other places in the draft.)

(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?

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?

There has been broad agreement within the working group on the
proposed encoding for some time. The main points of discussion
over the last several months has been over wordsmithing (and this
has not been an intense discussion). 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
http://www.ietf.org/ID-Checklist.html 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 warnings (reference to
PCN-metering-marking points to
draft-ietf-pcn-marking-behaviour-03
rather than the newer -04); reference PCN-architecture points to
draft-ietf-pcn-architecture-11 rather than RFC 5559)..
There is no MIB, media type, nor URI related-text in the
document.

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

There is a normative reference to
draft-ietf-pcn-marking-behaviour-04, which has recently been
submitted to the IESG.

(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 the 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 specifies a baseline encoding for pre-congestion
notification states in a PCN domain. The baseline encoding
assumes
that the ECN bits in the IP header can be used to encode two PCN
states ("Not-marked", "PCN-marked") for packets belonging to
certain
Diffserv behavior aggregates. The PCN-compatible Diffserv
codepoints
are not specified, and are assumed to be configurable on a domain
basis. It is assumed that normal ECN behavior is not available
for
packets within these behavior aggregates; however, the encoding
allows
packets in these behavior aggregates to be marked as "Not-PCN".
The
proposed alternative semantics of the ECN bits is consistent with
the
rules specified in RFC 4774.

Working Group Summary

The proposed encoding is the product of substantial discussion
within
group.

Document Quality

The document was reviewed by the document shephard
(Steven Blake).