Re: [PCN] Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt

[<[e-mail]>]

The -04 version of this draft resolves all of my comments
from the Gen-ART review of the -03 version.

While it would be better to change the term "PCN-excess-rate"
to something else in a perfect world, the world is not
perfect - since that is now the established term for the
concept of a PCN configured rate above which all traffic is
excess, it should be left as is.

Thanks,
--David
 

> -----Original Message-----
> From: Black, David 
> Sent: Thursday, June 18, 2009 3:32 PM
> To: [e-mail]; Gen Art
> Cc: Black, David; Scott Bradner; Steven Blake; Lars Eggert; 
> [e-mail]
> Subject: Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt
> 
> I have been selected as the General Area Review Team (Gen-ART) 
> reviewer for this draft (for background on Gen-ART, please see 
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call
> comments  you may receive. 
> 
> Document: draft-ietf-pcn-marking-behaviour-03.txt
> Reviewer: David L. Black
> Review Date: 18 June 2008
> IETF LC End Date: 18 June 2008
> 
> Summary: 
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
> 
> Comments:
> 
> This draft specified requirements on how the diffserv components
> in a PCN node need to behave in order to support PCN.  In addition
> to specifying the requirements, an example algorithm (Appendix
> A) and extensive implementation notes (Appendix B) are provided.
> The implementation notes are very useful - the WG should be
> commended for working through the practical implementation
> considerations for this functionality up front as opposed to
> leaving them to implementers to puzzle out.
> 
> All of my comments are on relatively minor points:
> 
> "PCN-excess-rate" strikes me as a bad name for a configured
> throughput rate - I suggest choosing another term.  Intuitively,
> I would expect PCN-excess-rate to refer to traffic that is in
> excess of a PCN configured rate.
> 
> Section 2.1, 1st paragraph and Section B.3 need to cite a
> reference for how the DSCP and ECN field values are used to
> decide whether a packet is PCN or not.
> 
> In Section 2.2, first bullet, what is "scheduling rate"?  Please
> supply a definition.
> 
> Section 2.4 - the second bullet also applies to competing non-PCN
> traffic (if that traffic is metered).  The text needs to be adjusted
> to allow for this.  Try:
> 
>   A packet SHOULD NOT be metered ...
> 
>   o If the PCN-packet is already ....
> 
>   o If this PCN-node drops the packet.
> 
> Section 2.5 could use a reminder that while competing non-PCN packets
> may be metered, they MUST NOT be marked.  This may have implications
> for the marking behavior that are probably most usefully discussed
> in Appendix B.
> 
> Nits:
> - At the end of the first paragraph in B.1
> 	"there needs to be" --> "there should be"
>   The "should" is lower case.
> 
> - idnits 2.11.11 noted that there is now a -04 version of the
> 	pcn-baseline-encoding draft, as was noted in the draft
> 	shepherd's writeup.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
>