Subject: [Gen-art] A *new* batch of IETF LC reviews - 2011-12-30

From: Mary Barnes <[email-masked]>
Date: Fri, 30 Dec 2011 14:46:53 -0600

Hi all,

Here's the link to the new LC assignments:
http://wiki.tools.ietf.org/dav/genart/reviewers-111230-lc.html

The assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

And I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

The standard template is included below.

Thanks,

Mary

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 31 Dec 2011 16:50:05 -0500

Document: draft-ietf-pcn-sm-edge-behaviour-08
     PCN Boundary Node Behaviour for the Single Marking (SM) Mode of
                                Operation
Reviewer: Joel M. Halpern
Review Date: 31-Dec-2011
IETF LC End Date: 13-Jan-2012
IESG Telechat date: N/A

Summary: This documents is almost ready for publication as an 
Informational RFC.

Question:  Given that the document defines a complex set of behaviors, 
which are mandatory for compliant systems, it seems that this ought to 
be Experimental rather than Informational.  It describes something that 
could, in theory, later become standards track.

Major issues:
     Section 2 on Assumed Core Network Behavior for SM, in the third 
bullet, states that the PCN-domain satisfies the conditions specified in 
RFC 5696.  Unfortunately, look at RFC 5696 I can not tell what 
conditions these are.  Is this supposed to be a reference to RFC 5559 
instead?  No matter which document it is referencing, please be more 
specific about which section / conditions are meant.

     It would have been helpful if the early part of the document 
indicated that the edge node information about how to determine 
ingress-egress-aggregates was described in section 5.
     In conjunction with that, section 5.1.2, third paragraph, seems to 
describe an option which does not seem to quite work.  After describing 
how to use tunneling, and how to work with signaling, the text refers to 
inferring the ingress-egress-aggregate from the routing information.  In 
the presence of multiple equal-cost domain exits (which does occur in 
reality), the routing table is not sufficient information to make this 
determination.  Unless I am very confused (which does happen) this seems 
to be a serious hole in the specification.

Minor issues:
     Section 3.3.1 states that the "block" decision occurs when the CLE 
(excess over total) rate exceeds the configured limit.  However, section 
3.3.2 states that the decision node must take further stapes if the 
excess rate is non-zero in further reports.  Is this inconsistency 
deliberate?  If so, please explain.  If not, please fix.  (If it is 
important to drive the excess rate to 0, then why is action only 
initiated when the ratio is above a configured value, rather than any 
non-zero value?  I can conceive of various reasons.  But none are stated.)

Nits/editorial comments: