Re: [re-ECN] Other transports than TCP in charter

<toby.moncaster@bt.com> Fri, 13 November 2009 14:57 UTC

Return-Path: <toby.moncaster@bt.com>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF1C3A69A5 for <re-ecn@core3.amsl.com>; Fri, 13 Nov 2009 06:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1l9UdHO1uQ4 for <re-ecn@core3.amsl.com>; Fri, 13 Nov 2009 06:57:40 -0800 (PST)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 71B0A3A685D for <re-ecn@ietf.org>; Fri, 13 Nov 2009 06:57:40 -0800 (PST)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 14:37:46 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Nov 2009 14:36:52 -0000
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70DF1CADE@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <EC9F0C58-47E0-433B-BE0D-B9220DC4289E@g11.org.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] Other transports than TCP in charter
Thread-Index: AcpkbRODdsp44DcySxqGc2nbosEH9AAAQ7ZQ
References: <130EBB38279E9847BAAAE0B8F9905F8C023967DD@esealmw109.eemea.ericsson.se><36a593230911121809m2b1322cctfcc124f5b7ec707@mail.gmail.com><200911131311.nADDBl2M011699@bagheera.jungle.bt.co.uk> <EC9F0C58-47E0-433B-BE0D-B9220DC4289E@g11.org.uk>
From: <toby.moncaster@bt.com>
To: <carlberg@g11.org.uk>
X-OriginalArrivalTime: 13 Nov 2009 14:37:46.0356 (UTC) FILETIME=[DDC86B40:01CA646E]
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] Other transports than TCP in charter
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 14:57:41 -0000

There may need to be some careful wordsmithing of the charter to have
one that isn't overly restrictive but which ensures we end up with a
realistic work stack. I am still torn, but I would perhaps favour
something in the charter like

"initially we will be concentrating on TCP but given the growing
importance of other transports these are not being explicitly excluded.
Specific milestones are set out below for TCP with the intention that as
these are met, effort can be moved to alternative transports" 

Or something along those lines anyway...

Toby

> -----Original Message-----
> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> Behalf Of ken carlberg
> Sent: 13 November 2009 14:25
> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Cc: Ingemar Johansson S; re-ecn@ietf.org
> Subject: Re: [re-ECN] Other transports than TCP in charter
> 
> Bob,
> 
> > I want to manage expectations here.
> 
> I'm positive the ADs are thrilled to read this :-)
> 
> The thing I (and probably Ingemar) would ideally like to see is a
> charter that doesn't preclude the introduction of proposed work
> involving transports other than TCP.  This is perhaps a question to
the
> chairs/ADs, but would it be possible to have a charter that makes a
> more general statement about transport protocols, and then for now
have
> a specific milestone that only identifies a work item for TCP and no
> other transport protocol?
> 
> the advantage in doing something like this is that if one of us were
to
> come up with an idea that addresses UDP via RTP/RTCP, then we could
> introduce it to the group for their consideration without having to
ask
> for a change in the charter.  And by the same token, by not listing
> other transports as a current milestone, we don't commit the proposed
> group to something that could be considered too much / too soon.
> 
> -ken
> 
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn