Re: [Gen-art] Gen-ART review of draft-livingood-woundy-p4p-experiences-07
Thanks for the detailed review, Spencer! I'll set aside some time next week to review your comments and then make necessary changes as needed in the draft to address this in a -08 version. Regards Jason On 5/27/09 9:55 PM, Spencer Dawkins spen...@wonderhamster.org wrote: 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-livingood-woundy-p4p-experiences-07 Reviewer: Spencer Dawkins Review Date: 2009-05-27 IETF LC End Date: 2009-06-16 IESG Telechat date: (not known) Summary: This document is nearly ready for publication as an Informational RFC. I did identify some minor issues (listed below) that should be considered as this document moves forward in the approval process. I also identified some nits, which aren't actually part of the Gen-ART review but are included for the convenience of the editor. Thanks, Spencer 1. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [RFC2119]. Spencer (nit): idnits says no 2119 keywords in the document, so this section can be deleted (along with the [rfc2119] reference. 2. Introduction Comcast is a large broadband ISP, based in the U.S., serving the Spencer (nit): http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt doesn't list ISP as an abbreviation that isn't expanded (please expand on first use). majority of its customers via cable modem technology. A trial was conducted in July 2008 with Pando Networks, Yale, and several ISP members of the P4P Working Group, which is part of the Distributed Computing Industry Association (DCIA). Comcast is a member of the DCIA's P4P Working Group, whose mission is to work with Internet service providers (ISPs), peer-to-peer (P2P) companies, and technology researchers to develop P4P mechanisms, such as so-called iTrackers (hereafter P4P iTrackers), that accelerate distribution of content and optimize utilization of ISP network resources. P4P iTrackers theoretically allow P2P networks to optimize traffic within each ISP, reducing the volume of data traversing the ISP's infrastructure and creating a more manageable flow of data. P4P iTrackers can also accelerate P2P downloads for end users. The P4P iTracker trial was conducted, in cooperation with Pando, Yale, and three other P4P member ISPs, from July 2 to July 17, 2008. This was the first P4P iTracker trial over a cable broadband network. The trial used a Pando P2P client, and Pando distributed a special 21 MB licensed video file in order to measure the effectiveness of P4P Spencer (nit): suggest s/21 MB/21-MB/ for clarity iTrackers. A primary objective of the trial was to measure the effects that increasing the localization of P2P swarms would have on Spencer (minor): it would be helpful to add a definition for swarm - everyone kind of knows what you're talking about, but it's not even defined in Wikipedia :-) (per http://en.wikipedia.org/wiki/Swarm_(disambiguation))... P2P uploads, P2P downloads, and ISP networks, in comparison to normal P2P activity. 3. High-Level Details There were five different swarms for the content used in the trial. The first was a random P2P swarm, as a control group. The second, third, and fourth used different P4P iTrackers: Generic, Coarse Grained, and Fine Grained, all of which are described in Section 4. The fifth was a proprietary Pando mechanism. (The results of the fifth swarm, while very good, are not included here since our focus Spencer (minor): while very good is slightly more marketing-speak than I was comfortable with... the ADs can ignore this comment, of course. is on open standards and a mechanism which may be leveraged for the benefit of the entire community of P2P clients.) Comcast deployed a P4P iTracker server in its production network to support this trial, and configured multiple iTracker files to provide varying levels of localization to clients. 4.1. P4P Fine Grain The Fine Grain topology was the first and most complex P4P iTracker that we built for this trial. It was a detailed mapping of Comcast backbone-connected network Autonomous System Numbers (ASN) to IP Aggregates which were weighted based on priority and distance from each other. Included in this design was a prioritization of all Peer and Internet transit connected ASNs to the Comcast backbone to ensure that P4P traffic would prefer settlement free and lower cost networks first, and then more expensive transit links.
Re: [Gen-art] review of draft-ietf-pce-monitoring-04.txt
Last call is over. Please respin (I see the most recent version dated January 2009). thanks, Ross -Original Message- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 28 April 2009 01:37 To: Ross Callon Cc: Francis Dupont; General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Ah yes, I thought the IETF LC was ended. Will respin right after that. Thanks Ross. JP. On Apr 25, 2009, at 7:10 AM, Ross Callon wrote: You need to wait for the IETF last call to end before respinning. Once the IETF last call ends, then yes please respin. Thanks, Ross -Original Message- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 24 April 2009 02:05 To: Francis Dupont; Ross Callon Cc: General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Many Thanks Francis. Ross, do you want me to address those comments and respin ? Thanks. JP. On Apr 23, 2009, at 11:46 PM, Francis Dupont wrote: 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-pce-monitoring-04.txt Reviewer: Francis Dupont Review Date: 2009-04-22 IETF LC End Date: 2009-04-27 IESG Telechat date: unknown Summary: Not Ready Major issues: none but some minor issues which should need another cycle. Minor issues: - 1 page 5: as the PCReq/PCReq seem to come from nowhere in 3.1 page 8 IMHO it is the right place to introduce them, for instance (it should be hard to be simpler) add after the first path computation request the comment (PCReq message). Perhaps this is not the right thing but it should be clear from the introduction the document both specifies new messages and new objects, and these new objects can be used in PCReq/PCRep too. - 4.1 page 12: incompatible requirement There SHOULD NOT be more than one instance of the MONITORING object with PCRep syntax (response-list) - 4.1 page 13: even if MONITORING object has no optional TLV currently defined, the format of these TLVs must be specified. I propose the PCEP generic TLV format, RFC 5440 7.1. - 4.3 page 16: the variance of time is a squared time. I propose to switch to standard deviation (ecart type in French, the square root of the variance) - 8.6 page 23: CONGESTION object has no defined flag. (this is not editorial because of IANA review/processing) Nits/editorial comments: - Abstract page 2 is in one block, I suggest to insert a line break before In PCE-based - Requirements Language page 2 should be moved in the terminology section - ToC page 3 / 8.3 page 21: New Error-Type and Error-Values - New Error-Values - ToC page 3 and 10 page 23: Acknowledgements - Acknowledgments - 1 page 4: IGP - Interior Gateway Protocol (IGP) - 1 page 4: troubeshooting - troubleshooting - 1 page 4: more than one PCE is - are? - 1 page 4: BRPC - Backward Recursive PCE-based Computation (BRPC) - 1 page 5: bolean - boolean - 1 page 5: By In band - By in band - 1 page 5 and many other places: e.g. - e.g., - 3 page 6: PCEMonReq - PCMonReq - 3 page 6: too many in this document (wording) - 3.1 page 8: insert a line break between: svec-list::=SVEC[svec-list] request-list::=request[request-list] - 3.1 page 8: Section 4.2.) - Section 4.2) - 3.1 page 8: charaterize - characterize - 3.1 page 9: PCMonreq - PCMonReq - 3.2 page 11: PROC-TIME and CONGESTION are defined further (8. [56]). where NO-PATH is defined? - 4.1 page 13: choose between Monitoring-id-number and monitoring-id- number - 4.1 page 13: a wrap back to one is unclear, 0x + 1 == 0, not 1. If the value zero is reserved this should be more explicit. - 4.3 page 15 1): Min, Average, Max and Variance - minimum, maximum, average and variance - 4.2 page 15 2): Procesing-time - Processing-time - 4.4 page 17: currently defined: - currently defined. - 6 page 18: value=Reception of an unacceptable number of unknown PCEP message. - value=5 Reception of an unacceptable number of unrecognized PCEP message. (i.e., put the reason value and correct meaning with a closing , BTW there are two occurrences to fix) - 6 page 19: in the next hop PCE: such next-hop choose between next-hop and next hop (I prefer the second). - 6 page 19: extra Upon receiving a PCMonRep message - 6 page 19: carrries - carries - 6 page 19: Multi-destination - multi-destination - 8.2 page 20 (last line): are defined in this document. - are defined in this document: - 8.3 page 21: as it doesn't define new error-type(s) I propose: New Error-Type and Error-Values - New Error-Values - 8.3 page 21: has been created - was created? - 9 page 23: denail - denial -
[Gen-art] A *new* batch of IETF LC reviews - 28 May 2009
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-090528-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Thanks, Mary. --- 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: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Assignments for June 4, 2009 Telechat
Hi all, Here's the link to the summary of assignments for the June 4, 2009 telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-090604.html With the updated spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html Mary. --- 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IESG Telechat date: 4 June 2009 Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
