Philip, These suggested changes look fine, and I like Michael Menth's idea of rephrasing the text to discuss "reference rates of the meters and markers" instead of "PCN-excess-rate".
Thanks, --David > -----Original Message----- > From: gen-art-boun...@ietf.org > [mailto:gen-art-boun...@ietf.org] On Behalf Of philip.eard...@bt.com > Sent: Friday, June 19, 2009 8:57 AM > To: Black, David; gen-art@ietf.org > Cc: p...@ietf.org; s...@harvard.edu; slbl...@petri-meat.com > Subject: Re: [Gen-art] Gen-ART review > ofdraft-ietf-pcn-marking-behaviour-03.txt > > David, > Thanks for your review & comments. > > { 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. > Thanks! > > { "PCN-excess-rate" strikes me as a bad name for a configured > { throughput rate - I suggest choosing another term. > To be honest, I think it's too late to change it, as it's defined/used > in the PCN architecture doc, which has just become RFC5559. > > { 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. > Ok, will add "For instance, the baseline encoding [ref]." > > { > { In Section 2.2, first bullet, what is "scheduling rate"? Please > { supply a definition. > > I think the bullet needs re-phrasing. Here's what it says at the > moment:- > <<On all links in the PCN-domain, dropping MAY be done by: > o metering all metered-packets to determine if the rate > of metered- > traffic is greater than its scheduling rate (ie determine if any > packets are out-of-profile). > >> > > how about the following? > On all links in the PCN-domain, dropping MAY be done by: > o metering all metered-packets to determine if the rate > of metered- > traffic on the link is greater than the rate allowed for such > traffic. > > { > { 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. > > Good spot, thanks > > { > { 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. > > ok, will add reminder. > > { > { 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 > { +1 (508) 293-7953 FAX: +1 (508) 293-7786 > { black_da...@emc.com Mobile: +1 (978) 394-7754 > { ---------------------------------------------------- > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
