I'm guessing people are thinking of this ION: http://wiki.tools.ietf.org/group/iesg/trac/browser/ions/approved/ion-tsv-alt-cc.txt Previously, this course of action (using ICCRG to vet "safety" of a proposed Experimental document before progressing in IETF) was used with Compound TCP, CUBIC, and H-TCP. It has been much slower of a process than expected, and though some positive results and interactions have come about, it hasn't been an effective way to get Experimental documents published by IETF WGs yet. Based on that experience, I'd probably do things slightly differently in the future ... leaving dates open-ended is definitely one thing to avoid. Bounding the dates gives "making progess" priority over having a length evaluation, but after discussions in the ICCRG, I think a lot of people seem to be comfortable with that. If something like this is to be done with MulTFRC for DCCP, I would suggest that something like a "request for information" be sent from coordinated DCCP and ICCRG chairs to the ICCRG with bounded timeframe (like 2 months) for comments to come in. At the end of that timeframe, someone from ICCRG could post a summary write-up to DCCP. Just a suggestion ... as an ICCRG co-chair, I'd be willing to help with this. We'd have to check with the other ICCRG co-chair too :). --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- >-----Original Message----- >From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of >Gorry Fairhurst >Sent: Tuesday, October 13, 2009 3:26 PM >To: Phelan, Tom >Cc: dccp >> 'dccp' working group >Subject: Re: Mul-TFRC (draft-welzl-multfrc-00) > > >Tom, > >I don't see anything in the Charter about using DCCP as a platform for >experimental standards - although clearly you *could* do that and there >are codepoints for experimentation, and that is fine. I was urging >restraint in standardising these new CCIDs. > >I also recall that ICCRG would be the first point point of review for >transport protocols that were not already deployed, or needed review >prior to being taken to a WG. I don't recall a special case for ICCRG in >the DCCP charter text. > >Gorry > >Phelan, Tom wrote: >> Hi Gorry, >> >> It's been a while since I read the DCCP charter carefully, but I seem >to >> remember something about cooperating with ICCRG to experiment with new >> congestion control protocols. My take on that is that we should >> consider creating experimental-track RFCs for protocols that have some >> level of support from the ICCRG (we can discuss what that level of >> support should be). >> >> One of the benefits of doing this through DCCP is that the congestion >> control protocol developer can concentrate on just that and let DCCP >> carry the burden of the rest of what makes a transport protocol. This >> seems to me to be good for the CC developers and good for DCCP, even >> though it won't necessarily lead to production deployment of DCCP >> (unless one of these CC protocols is a hit :-)). >> >> Tom P. >>
