Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP

Lars Eggert <lars.eggert@nokia.com> Mon, 28 May 2007 07:38 UTC

Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZo6-0004d9-9E; Mon, 28 May 2007 03:38:22 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1HsZo4-0004cu-6x for tsvwg-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 03:38:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZo0-0004cg-5d; Mon, 28 May 2007 03:38:16 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsZnz-0002p9-Gb; Mon, 28 May 2007 03:38:16 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4S7beZD013309; Mon, 28 May 2007 10:38:05 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 10:37:58 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 10:37:57 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 10:37:57 +0300
Received: from [172.21.37.17] (esdhcp03717.research.nokia.com [172.21.37.17]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4S7btLj006166; Mon, 28 May 2007 10:37:56 +0300
In-Reply-To: <Pine.LNX.4.64.0705261326060.9359@netcore.fi>
References: <20070523135426.6DEB2213853@lawyers.icir.org> <Pine.LNX.4.64.0705261326060.9359@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-6-167205329"; protocol="application/pkcs7-signature"
Message-Id: <E9103622-1156-4025-9404-8A28BFBDAE16@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
Date: Mon, 28 May 2007 10:37:47 +0300
To: ext Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 28 May 2007 07:37:57.0595 (UTC) FILETIME=[1C5582B0:01C7A0FB]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: tsvwg-chairs@tools.ietf.org, iccrg@cs.ucl.ac.uk, ietf@ietf.org, tsvwg@ietf.org, Mark Allman <mallman@icir.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On 2007-5-26, at 14:24, ext Pekka Savola wrote:
> (Note: this is still a draft version if you're referring to
> http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt)
>
> This model raises one fundamental question issue of the scope of  
> this document.
>
> Who should be evaluating section 3 and 4 of this document?  Is this  
> solely meant for ICCRG, the IETF or both?  If both, would both  
> parties do everything described in those documents?

The basic idea behind this ION is that a researcher would bring his  
or her proposal, papers and experimental data to the ICCRG, which  
would then evaluate whether a proposal is safe for experimentation in  
the Internet or in more restricted network environments. (According  
to draft-ietf-tsvwg-cc-alt, and probably also draft-irtf-tmrg- 
metrics.) That review will accompany the resulting -00 technical  
specification when it is brought to the IETF.

> It would be clearer if the reviewer was ICCRG, and the IETF would  
> not attempt to perform the same review, and the IETF wouldn't be  
> allowed to second-guess the proposal, e.g., that it's research has  
> not been done well enough if it was already positively evaluated by  
> ICCRG.

There is a strong expectation that the IETF would usually agree with  
the review recommendation that the ICCRG made, and take on the  
document. (Sufficient people overlap, the ICCRG has stronger  
congestion control expertise, etc.) But process-wise it *is* up the  
to the WG (likely TCPM) to come to consensus on whether they want to  
adopt any given work item, and that consensus call can't be  
outsourced to the ICCRG. But I would personally see it as a sign that  
something went very wrong if TCPM would not publish something as  
Experimental that came with a strong ICCRG review.

Lars

PS: I'm editing the ION in response to IESG comments. The latest  
working version is under http://www3.tools.ietf.org/group/iesg/trac/ 
browser/ions/drafts - I'd be interested in hearing suggestions on how  
the text could be improved.