From Martin.Stiemerling@neclab.eu Wed Jul 3 23:48:27 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407E021F9E46 for ; Wed, 3 Jul 2013 23:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.215 X-Spam-Level: X-Spam-Status: No, score=-103.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5fi956kc8OK for ; Wed, 3 Jul 2013 23:48:23 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAF521F9E3B for ; Wed, 3 Jul 2013 23:48:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CB9C6104948 for ; Thu, 4 Jul 2013 08:47:52 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPwNo9elFyna for ; Thu, 4 Jul 2013 08:47:52 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id AB435104947 for ; Thu, 4 Jul 2013 08:47:47 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 4 Jul 2013 08:48:16 +0200 Message-ID: <51D51AB0.2030604@neclab.eu> Date: Thu, 4 Jul 2013 08:48:16 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Subject: Draft agenda for the IETF-87 TSV Area meeting uploaded Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 06:48:27 -0000 Hi, Here is the draft agenda for the IETF-87 TSV Area meeting: Transport Area Open Meeting (tsvarea) -- IETF-87 THURSDAY, August 1, 2013 09:00-11:30 Draft Agenda: 09:00 Note Well and agenda bashing (5 minutes) 09:05 TSV/NOMCOM (15 minutes) 09:20 MPTCP Update (30 minutes) 09:50 QUIC protocol introduction (45 minutes) -- tentative 10:35 Online Games Tutorial (45 minutes) The link to the current version: http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvarea Let Spencer and me know if you have something that should be on the agenda. Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From ietfdbh@comcast.net Thu Jul 4 07:25:30 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA80621F9F89 for ; Thu, 4 Jul 2013 07:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.837 X-Spam-Level: X-Spam-Status: No, score=-99.837 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuWlhqUdb65Y for ; Thu, 4 Jul 2013 07:25:26 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id DB87521F9F86 for ; Thu, 4 Jul 2013 07:25:25 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id wD7N1l0071wpRvQ51ERR2k; Thu, 04 Jul 2013 14:25:25 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id wERQ1l00n2yZEBF3eERQpn; Thu, 04 Jul 2013 14:25:25 +0000 From: "ietfdbh" To: "'Martin Stiemerling'" , References: <51D51AB0.2030604@neclab.eu> In-Reply-To: <51D51AB0.2030604@neclab.eu> Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Thu, 4 Jul 2013 10:25:00 -0400 Message-ID: <013501ce78c2$44ad9c20$ce08d460$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3LqKzN4QJBbDJ1osACnOi5d6rhpiDJngA Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372947925; bh=Cm4T4v8QZ2YEhgH5goW2uI1ysqq4wg7H+Z3momJBA9o=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=W5sUiafPBAyY+pYlW8OgubGQv078rYiQgrEeZrVFUxzLNCSxkSkApThK4BybHBUTg mLIocKesMYd7YQdofKy3wu2wcDTcjnkRtxXsMf2IAjtDVdl6mDpfOfwDxPYEzm/KOn QuRrivSCRAhV7iST8kN/HL8o9HfO+DAExwxxrqrLXtSTg1Th57ngKevR90vKBw3vsF BFcMFHH/KvVDIzbnWSusLJjUP1qGIWqMh3AyLjcgPCn0hiBIGS70WtSWt22T48VcyM 6naAwmY4AcPyVJ/IWWCb/iS8FGVwdkn+8VtW//XoxpEcCLaq8Nc/NbzMmclzOUzUBH WFux9M+O6zxEw== X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:25:30 -0000 Hi, What is QUIC? Is there a draft? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > Behalf Of Martin Stiemerling > Sent: Thursday, July 04, 2013 2:48 AM > To: tsv-area@ietf.org > Subject: Draft agenda for the IETF-87 TSV Area meeting uploaded > > Hi, > > Here is the draft agenda for the IETF-87 TSV Area meeting: > Transport Area Open Meeting (tsvarea) -- IETF-87 THURSDAY, August 1, 2013 > 09:00-11:30 > > Draft Agenda: > 09:00 Note Well and agenda bashing (5 minutes) > 09:05 TSV/NOMCOM (15 minutes) > 09:20 MPTCP Update (30 minutes) > 09:50 QUIC protocol introduction (45 minutes) -- tentative > 10:35 Online Games Tutorial (45 minutes) > > The link to the current version: > http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvarea > > > Let Spencer and me know if you have something that should be on the > agenda. > > Martin > > -- > martin.stiemerling@neclab.eu > > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 From swmike@swm.pp.se Thu Jul 4 08:10:36 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6F611E8134 for ; Thu, 4 Jul 2013 08:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CloXP3ACvyPh for ; Thu, 4 Jul 2013 08:10:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E628411E8133 for ; Thu, 4 Jul 2013 08:10:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0CCCC9C; Thu, 4 Jul 2013 17:10:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 00A0A9A; Thu, 4 Jul 2013 17:10:33 +0200 (CEST) Date: Thu, 4 Jul 2013 17:10:33 +0200 (CEST) From: Mikael Abrahamsson To: ietfdbh Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded In-Reply-To: <013501ce78c2$44ad9c20$ce08d460$@comcast.net> Message-ID: References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:10:36 -0000 On Thu, 4 Jul 2013, ietfdbh wrote: > Hi, > > What is QUIC? Is there a draft? https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true http://blog.chromium.org/2013/06/experimenting-with-quic.html http://en.wikipedia.org/wiki/QUIC -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Thu Jul 4 17:38:40 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD11511E821B for ; Thu, 4 Jul 2013 17:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.766 X-Spam-Level: X-Spam-Status: No, score=-105.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYFTAGAgHY4F for ; Thu, 4 Jul 2013 17:38:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 51C8711E80F9 for ; Thu, 4 Jul 2013 17:38:36 -0700 (PDT) Received: from [172.35.3.4] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r650btCl016953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jul 2013 17:38:05 -0700 (PDT) Message-ID: <51D61564.9070900@isi.edu> Date: Thu, 04 Jul 2013 17:37:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 00:38:41 -0000 A link to a draft would be useful. A slot should not be granted if there isn't a draft. Joe On 7/4/2013 8:10 AM, Mikael Abrahamsson wrote: > On Thu, 4 Jul 2013, ietfdbh wrote: > >> Hi, >> >> What is QUIC? Is there a draft? > > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true > > http://blog.chromium.org/2013/06/experimenting-with-quic.html > http://en.wikipedia.org/wiki/QUIC > From swmike@swm.pp.se Thu Jul 4 22:42:12 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B739611E823F for ; Thu, 4 Jul 2013 22:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jnWUyzVpDrq for ; Thu, 4 Jul 2013 22:42:12 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 332FE11E8233 for ; Thu, 4 Jul 2013 22:42:11 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2B3609C; Fri, 5 Jul 2013 07:42:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2578A9A; Fri, 5 Jul 2013 07:42:10 +0200 (CEST) Date: Fri, 5 Jul 2013 07:42:10 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded In-Reply-To: <51D61564.9070900@isi.edu> Message-ID: References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 05:42:12 -0000 On Thu, 4 Jul 2013, Joe Touch wrote: > A slot should not be granted if there isn't a draft. Why? Is there some really important principle I'm missing here? https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true Yes, I'm sure this document could be reformatted into a draft without excessive work and it must be if the work is to take place in an IETF WG, but do you really want to deny the presentation on this (I guess formal?) requirement? I am not in any way affiliated with QUIC development, I have just read the document and find it interesting. -- Mikael Abrahamsson email: swmike@swm.pp.se From jsaldana@unizar.es Fri Jul 5 00:24:31 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F7B21F972E for ; Fri, 5 Jul 2013 00:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atY62AHXhKo0 for ; Fri, 5 Jul 2013 00:24:26 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1811F21F8FE5 for ; Fri, 5 Jul 2013 00:24:25 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r657OHFM007602; Fri, 5 Jul 2013 09:24:17 +0200 From: "Jose Saldana" To: "'Martin Stiemerling'" , References: <51D51AB0.2030604@neclab.eu> In-Reply-To: <51D51AB0.2030604@neclab.eu> Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Fri, 5 Jul 2013 09:24:18 +0200 Organization: Universidad de Zaragoza Message-ID: <003001ce7950$abe85e00$03b91a00$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3LqKzN4QJBbDJ1osACnOi5d6rhpiEQcEg Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 07:24:31 -0000 Hi, Martin. Regarding the "Online Games Tutorial", Mirko and I are adjusting the presentation in order to spend just 45 minutes. We have received some interesting suggestions after announcing it in the IETF87attendees mailing list. We think we will show and capture the traffic of 3 different games: - A UDP-based "First person shooter" - A UDP-based car racing game, including a 2-minutes car race in which some people in the room (and some remote ones) will be able to participate. - A TCP-based "Massively Multiplayer Online Role Play Game (MMORPG) One question: the tutorial is scheduled at 10.35. It lasts 45 minutes. Should we understand that from 11.20 to 11.30 we will have some time for questions and answers? Thanks! Jose > -----Mensaje original----- > De: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] En > nombre de Martin Stiemerling > Enviado el: jueves, 04 de julio de 2013 8:48 > Para: tsv-area@ietf.org > Asunto: Draft agenda for the IETF-87 TSV Area meeting uploaded > > Hi, > > Here is the draft agenda for the IETF-87 TSV Area meeting: > Transport Area Open Meeting (tsvarea) -- IETF-87 THURSDAY, August 1, 2013 > 09:00-11:30 > > Draft Agenda: > 09:00 Note Well and agenda bashing (5 minutes) > 09:05 TSV/NOMCOM (15 minutes) > 09:20 MPTCP Update (30 minutes) > 09:50 QUIC protocol introduction (45 minutes) -- tentative > 10:35 Online Games Tutorial (45 minutes) > > The link to the current version: > http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvarea > > > Let Spencer and me know if you have something that should be on the > agenda. > > Martin > > -- > martin.stiemerling@neclab.eu > > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 From Martin.Stiemerling@neclab.eu Fri Jul 5 01:36:55 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B49211E8275 for ; Fri, 5 Jul 2013 01:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT-PsrqKcoae for ; Fri, 5 Jul 2013 01:36:51 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F1EC911E8271 for ; Fri, 5 Jul 2013 01:36:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9EB121042F2; Fri, 5 Jul 2013 10:36:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iIQDM+A5clc; Fri, 5 Jul 2013 10:36:18 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 85AB61042ED; Fri, 5 Jul 2013 10:36:03 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 5 Jul 2013 10:36:33 +0200 Message-ID: <51D68591.4090004@neclab.eu> Date: Fri, 5 Jul 2013 10:36:33 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded References: <51D51AB0.2030604@neclab.eu> <003001ce7950$abe85e00$03b91a00$@unizar.es> In-Reply-To: <003001ce7950$abe85e00$03b91a00$@unizar.es> Content-Type: text/plain; charset="ISO-8859-2"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: =?ISO-8859-2?Q?Mirko_Su=BEnjevi=E6?= , tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 08:36:55 -0000 On 07/05/2013 09:24 AM, Jose Saldana wrote: > Hi, Martin. > > Regarding the "Online Games Tutorial", Mirko and I are adjusting the > presentation in order to spend just 45 minutes. We have received some > interesting suggestions after announcing it in the IETF87attendees mailing > list. We think we will show and capture the traffic of 3 different games: > - A UDP-based "First person shooter" > - A UDP-based car racing game, including a 2-minutes car race in which some > people in the room (and some remote ones) will be able to participate. > - A TCP-based "Massively Multiplayer Online Role Play Game (MMORPG) > > One question: the tutorial is scheduled at 10.35. It lasts 45 minutes. > Should we understand that from 11.20 to 11.30 we will have some time for > questions and answers? The 10 minutes are the end are reserved as buffer and you should not plan this for Q&A. Martin > > Thanks! > > Jose > >> -----Mensaje original----- >> De: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] En >> nombre de Martin Stiemerling >> Enviado el: jueves, 04 de julio de 2013 8:48 >> Para: tsv-area@ietf.org >> Asunto: Draft agenda for the IETF-87 TSV Area meeting uploaded >> >> Hi, >> >> Here is the draft agenda for the IETF-87 TSV Area meeting: >> Transport Area Open Meeting (tsvarea) -- IETF-87 THURSDAY, August 1, 2013 >> 09:00-11:30 >> >> Draft Agenda: >> 09:00 Note Well and agenda bashing (5 minutes) >> 09:05 TSV/NOMCOM (15 minutes) >> 09:20 MPTCP Update (30 minutes) >> 09:50 QUIC protocol introduction (45 minutes) -- tentative >> 10:35 Online Games Tutorial (45 minutes) >> >> The link to the current version: >> http://www.ietf.org/proceedings/87/agenda/agenda-87-tsvarea >> >> >> Let Spencer and me know if you have something that should be on the >> agenda. >> >> Martin >> >> -- >> martin.stiemerling@neclab.eu >> >> NEC Laboratories Europe >> NEC Europe Limited >> Registered Office: >> Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB >> Registered in England 2832014 > -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From Martin.Stiemerling@neclab.eu Fri Jul 5 01:40:37 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2237811E825E for ; Fri, 5 Jul 2013 01:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.3 X-Spam-Level: X-Spam-Status: No, score=-103.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1G5EA7b6t-x for ; Fri, 5 Jul 2013 01:40:33 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 465B811E8264 for ; Fri, 5 Jul 2013 01:40:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F0AE11042F2; Fri, 5 Jul 2013 10:40:02 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9IlgibEiT0x; Fri, 5 Jul 2013 10:40:02 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D8DDA1042ED; Fri, 5 Jul 2013 10:39:52 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 5 Jul 2013 10:40:01 +0200 Message-ID: <51D68661.5030205@neclab.eu> Date: Fri, 5 Jul 2013 10:40:01 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> In-Reply-To: <51D61564.9070900@isi.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 08:40:37 -0000 Hi Joe, On 07/05/2013 02:37 AM, Joe Touch wrote: > A link to a draft would be useful. There is no draft but this is of interest to the transport community at large. And it is tentative right now as we do not know if there will be this presentation, i.e., waiting for the confirmation. > > A slot should not be granted if there isn't a draft. That's true for working groups, but area meetings should have the possibility to talk about topics that are not (yet) documented in an Internet draft. This has also been done in the past, e.g., at IETF-77 for the RTMFP protocol: http://www.ietf.org/proceedings/77/slides/tsvarea-1.pdf Martin > > Joe > > On 7/4/2013 8:10 AM, Mikael Abrahamsson wrote: >> On Thu, 4 Jul 2013, ietfdbh wrote: >> >>> Hi, >>> >>> What is QUIC? Is there a draft? >> >> https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true >> >> >> http://blog.chromium.org/2013/06/experimenting-with-quic.html >> http://en.wikipedia.org/wiki/QUIC >> -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From l.wood@surrey.ac.uk Fri Jul 5 20:15:27 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7678021F9EA2 for ; Fri, 5 Jul 2013 20:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEBTd4WSSJS8 for ; Fri, 5 Jul 2013 20:15:23 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1921F9E9A for ; Fri, 5 Jul 2013 20:15:22 -0700 (PDT) Received: from [195.245.230.131:19014] by server-5.bemta-3.messagelabs.com id BE/46-15398-6CB87D15; Sat, 06 Jul 2013 03:15:18 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-78.messagelabs.com!1373080517!27779168!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30510 invoked from network); 6 Jul 2013 03:15:18 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-13.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jul 2013 03:15:18 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sat, 6 Jul 2013 04:15:17 +0100 From: To: , Date: Sat, 6 Jul 2013 04:15:15 +0100 Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Topic: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Index: Ac55GAfguQaX3APaSryhzy5pEbdS9QA23EHw Message-ID: <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> , <51D61564.9070900@isi.edu> In-Reply-To: <51D61564.9070900@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 03:15:27 -0000 Joe's assertion is wrong. The IETF is not the place where new transport protocols are developed. Tran= sport is recognised as an underresourced area; David Harrington's "Thoughts from a p= ast experimental Nomcom selection for TSV Area Director" http://www.ietf.org/mail-archive/web/ietf/current/msg77880.html discusses that, but did not at any point mention new protocols. The IETF ha= s no time for them, as it's too busy maintaining and finetuning and documenting the e= xisting ones. First deploy, then tell the IETF about it, and let the IETF put the documen= tation into the preferred 1970s ASCII format. draft-ietf-http-v10-spec-00 being the cla= ssic case in point, written up several years after global web domination. Setting up httpbis to tweak http, after spdy et al were developed outside t= he IETF and proven successful, is where the IETF is at - and httpbis isn't even in= the transport area, despite http increasingly looking like a transport and protocol hourg= lass waist. The IETF should be grateful that Google wants to tell it about a new transp= ort protocol that it has deployed worldwide. Demanding that it be written up as an inter= net-draft beforehand is unreasonable, and arguably a waste of effort. imho. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] On Behalf Of Jo= e Touch [touch@isi.edu] Sent: 05 July 2013 01:37 To: Mikael Abrahamsson Cc: tsv-area@ietf.org Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded A link to a draft would be useful. A slot should not be granted if there isn't a draft. Joe On 7/4/2013 8:10 AM, Mikael Abrahamsson wrote: > On Thu, 4 Jul 2013, ietfdbh wrote: > >> Hi, >> >> What is QUIC? Is there a draft? > > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRF= UoVD34/preview?sle=3Dtrue > > http://blog.chromium.org/2013/06/experimenting-with-quic.html > http://en.wikipedia.org/wiki/QUIC > From lars@netapp.com Fri Jul 5 23:00:37 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B055211E8119 for ; Fri, 5 Jul 2013 23:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.194 X-Spam-Level: X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[AWL=-2.595, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kENCUL-OEd88 for ; Fri, 5 Jul 2013 23:00:32 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3021F93C4 for ; Fri, 5 Jul 2013 23:00:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,1008,1363158000"; d="scan'208";a="32029177" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 05 Jul 2013 23:00:29 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.35]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 5 Jul 2013 23:00:28 -0700 From: "Eggert, Lars" To: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Topic: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Index: AQHOeIKLFFo5Yg0t/U2M+PLaENwyd5lVCNsAgAAMuoCAAJ6HAIAB7HsA Date: Sat, 6 Jul 2013 06:00:27 +0000 Message-ID: <1B951393-F02E-4E15-BDBF-824AA09F2E89@netapp.com> References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> In-Reply-To: <51D61564.9070900@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <689BFD2F0F0B8B46A54A680A3127B065@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 06:00:37 -0000 Hi, On Jul 5, 2013, at 2:37, Joe Touch wrote: > A slot should not be granted if there isn't a draft. when Magnus and me started TSVAREA, the intent was that it be an informatio= n dissemination session, and that IDs were not going to be published throug= h TSVAREA. (We have TSVWG for that.) That's different from other area meeti= ngs, such as INTAREA, that do push drafts. We had many presentations such as QUIC which did not come with drafts at th= e time (SMT, SPDY, RTFMP, etc.) Lars= From touch@isi.edu Fri Jul 5 23:17:14 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71E921F9F14 for ; Fri, 5 Jul 2013 23:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.584 X-Spam-Level: X-Spam-Status: No, score=-104.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL4ga+cR4nZa for ; Fri, 5 Jul 2013 23:17:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2A67A21F8628 for ; Fri, 5 Jul 2013 23:17:09 -0700 (PDT) Received: from [10.59.77.95] ([210.229.158.64]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r666FwsH021370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Jul 2013 23:16:18 -0700 (PDT) References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <1B951393-F02E-4E15-BDBF-824AA09F2E89@netapp.com> In-Reply-To: <1B951393-F02E-4E15-BDBF-824AA09F2E89@netapp.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4FFBCB6B-C059-477C-B0AB-5C0060C30690@isi.edu> X-Mailer: iPhone Mail (10B350) From: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Sat, 6 Jul 2013 15:15:42 +0900 To: "Eggert, Lars" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 06:17:15 -0000 Thanks - the area vs wg distinction makes sense.=20 Joe=20 On Jul 6, 2013, at 3:00 PM, "Eggert, Lars" wrote: > Hi, >=20 > On Jul 5, 2013, at 2:37, Joe Touch wrote: >> A slot should not be granted if there isn't a draft. >=20 > when Magnus and me started TSVAREA, the intent was that it be an informati= on dissemination session, and that IDs were not going to be published throug= h TSVAREA. (We have TSVWG for that.) That's different from other area meetin= gs, such as INTAREA, that do push drafts. >=20 > We had many presentations such as QUIC which did not come with drafts at t= he time (SMT, SPDY, RTFMP, etc.) >=20 > Lars From touch@isi.edu Sat Jul 6 00:04:42 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AE621F9DF7 for ; Sat, 6 Jul 2013 00:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.584 X-Spam-Level: X-Spam-Status: No, score=-104.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FGOX58MCRbb for ; Sat, 6 Jul 2013 00:04:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EF48621F9C6D for ; Sat, 6 Jul 2013 00:04:35 -0700 (PDT) Received: from [10.59.77.95] ([210.229.158.64]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r6673Gw3027605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Jul 2013 00:03:37 -0700 (PDT) References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> X-Mailer: iPhone Mail (10B350) From: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Sat, 6 Jul 2013 16:03:16 +0900 To: "" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 07:04:42 -0000 On Jul 6, 2013, at 12:15 PM, wrote: > First deploy, then tell the IETF about it, and let the IETF put the docume= ntation into > the preferred 1970s ASCII format. Unless drone revoked RFC 2780, that's the wrong sequence. First develop and= test, then tell the IETF in a standards- track RFC, then get that RFC appro= ved, then get a transport number, then deploy. =20 I don't mind general info about stuff in the area meetings, but feedback req= uires participation, which requires a draft. And deployment of transports re= quires approved standards to get assigned numbers.=20 Joe= From touch@isi.edu Sat Jul 6 00:16:03 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2413A21F9DE6 for ; Sat, 6 Jul 2013 00:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.584 X-Spam-Level: X-Spam-Status: No, score=-104.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5csYJYuYpFqQ for ; Sat, 6 Jul 2013 00:15:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 15B1E21F9DBB for ; Sat, 6 Jul 2013 00:15:57 -0700 (PDT) Received: from [10.59.77.95] ([210.229.158.64]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r667FP7d008626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Jul 2013 00:15:39 -0700 (PDT) References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> In-Reply-To: <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B350) From: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Sat, 6 Jul 2013 16:15:25 +0900 To: "" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 07:16:03 -0000 s/drone/someone/ set autocorrect=3Dfalse :-) On Jul 6, 2013, at 4:03 PM, Joe Touch wrote: >=20 >=20 > On Jul 6, 2013, at 12:15 PM, wrote: >=20 >> First deploy, then tell the IETF about it, and let the IETF put the docum= entation into >> the preferred 1970s ASCII format. >=20 > Unless drone revoked RFC 2780, that's the wrong sequence. First develop a= nd test, then tell the IETF in a standards- track RFC, then get that RFC app= roved, then get a transport number, then deploy. =20 >=20 > I don't mind general info about stuff in the area meetings, but feedback r= equires participation, which requires a draft. And deployment of transports r= equires approved standards to get assigned numbers.=20 >=20 > Joe From l.wood@surrey.ac.uk Sat Jul 6 02:21:03 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B340121F9B58 for ; Sat, 6 Jul 2013 02:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcIvEh5RJt9t for ; Sat, 6 Jul 2013 02:20:59 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8914021F9B8F for ; Sat, 6 Jul 2013 02:20:58 -0700 (PDT) Received: from [193.109.255.147:25195] by server-13.bemta-14.messagelabs.com id 1F/9F-15268-871E7D15; Sat, 06 Jul 2013 09:20:56 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-72.messagelabs.com!1373102455!11034712!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6736 invoked from network); 6 Jul 2013 09:20:56 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-15.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jul 2013 09:20:56 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sat, 6 Jul 2013 10:20:55 +0100 From: To: Date: Sat, 6 Jul 2013 10:20:55 +0100 Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Topic: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Index: Ac56FxTK9tmZeuaPQOisyEvJy/W9+wAEeu8I Message-ID: <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk> References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk>, <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> In-Reply-To: <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 09:21:03 -0000 Well, that's the wrong sequence, too. IANA can allocate numbers at draft st= age long before RFC - as it did for Saratoga http://saratoga.sf.net But even your sequence says 'tell the IETF', not 'participate in an IETF WG= with all the drones'. Since QUIC is already deployed worldwide, I am reminded of King Canute. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: Joe Touch [touch@isi.edu] Sent: 06 July 2013 08:03 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded On Jul 6, 2013, at 12:15 PM, wrote: > First deploy, then tell the IETF about it, and let the IETF put the docum= entation into > the preferred 1970s ASCII format. Unless drone revoked RFC 2780, that's the wrong sequence. First develop an= d test, then tell the IETF in a standards- track RFC, then get that RFC app= roved, then get a transport number, then deploy. I don't mind general info about stuff in the area meetings, but feedback re= quires participation, which requires a draft. And deployment of transports = requires approved standards to get assigned numbers. Joe From touch@isi.edu Sat Jul 6 11:34:33 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4A921F8BC0 for ; Sat, 6 Jul 2013 11:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT6YTpQLHq60 for ; Sat, 6 Jul 2013 11:34:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D891521F85C3 for ; Sat, 6 Jul 2013 11:34:28 -0700 (PDT) Received: from [10.66.136.190] (mobile-198-228-212-045.mycingular.net [198.228.212.45]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r66IXW9Q010428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Jul 2013 11:33:41 -0700 (PDT) References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <04D8DC43-2A1F-446C-A14E-863A41219F0F@isi.edu> X-Mailer: iPhone Mail (10B350) From: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Sat, 6 Jul 2013 11:33:32 -0700 To: "" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 18:34:33 -0000 And where in your sequence did a standard appear? Outside a wg? On Jul 6, 2013, at 2:20 AM, wrote: > Well, that's the wrong sequence, too. IANA can allocate numbers at draft s= tage long before RFC - as it did for Saratoga http://saratoga.sf.net >=20 > But even your sequence says 'tell the IETF', not 'participate in an IETF W= G with all the drones'. >=20 > Since QUIC is already deployed worldwide, I am reminded of King Canute. >=20 > Lloyd Wood > http://sat-net.com/L.Wood/ >=20 >=20 > ________________________________________ > From: Joe Touch [touch@isi.edu] > Sent: 06 July 2013 08:03 > To: Wood L Dr (Electronic Eng) > Cc: ; > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded >=20 > On Jul 6, 2013, at 12:15 PM, wrote: >=20 >> First deploy, then tell the IETF about it, and let the IETF put the docum= entation into >> the preferred 1970s ASCII format. >=20 > Unless drone revoked RFC 2780, that's the wrong sequence. First develop a= nd test, then tell the IETF in a standards- track RFC, then get that RFC app= roved, then get a transport number, then deploy. >=20 > I don't mind general info about stuff in the area meetings, but feedback r= equires participation, which requires a draft. And deployment of transports r= equires approved standards to get assigned numbers. >=20 > Joe From l.wood@surrey.ac.uk Sat Jul 6 14:56:51 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0021F9CF8 for ; Sat, 6 Jul 2013 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+xraxRdlRdT for ; Sat, 6 Jul 2013 14:56:46 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) by ietfa.amsl.com (Postfix) with ESMTP id EC2CE21F9BCA for ; Sat, 6 Jul 2013 14:56:38 -0700 (PDT) Received: from [195.245.230.131:51739] by server-4.bemta-3.messagelabs.com id 06/FB-24959-39298D15; Sat, 06 Jul 2013 21:56:35 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-78.messagelabs.com!1373147795!31099244!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27349 invoked from network); 6 Jul 2013 21:56:35 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-6.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jul 2013 21:56:35 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sat, 6 Jul 2013 22:56:34 +0100 From: To: Date: Sat, 6 Jul 2013 22:52:53 +0100 Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Topic: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Index: Ac56d3TQIzrnwDioSnOaoW0bbQaTEwAG7YYw Message-ID: <290E20B455C66743BE178C5C84F12408223F494EE1@EXMB01CMS.surrey.ac.uk> References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk>, <04D8DC43-2A1F-446C-A14E-863A41219F0F@isi.edu> In-Reply-To: <04D8DC43-2A1F-446C-A14E-863A41219F0F@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 21:56:51 -0000 Few RFCs are standards track. IETF transport focuses on maintaining its existing standards; that's my point. It's not really set up for experimental work not directly=20 related to those standards. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: Joe Touch [touch@isi.edu] Sent: 06 July 2013 19:33 To: Wood L Dr (Electronic Eng) Cc: Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded And where in your sequence did a standard appear? Outside a wg? On Jul 6, 2013, at 2:20 AM, wrote: > Well, that's the wrong sequence, too. IANA can allocate numbers at draft = stage long before RFC - as it did for Saratoga http://saratoga.sf.net > > But even your sequence says 'tell the IETF', not 'participate in an IETF = WG with all the drones'. > > Since QUIC is already deployed worldwide, I am reminded of King Canute. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > ________________________________________ > From: Joe Touch [touch@isi.edu] > Sent: 06 July 2013 08:03 > To: Wood L Dr (Electronic Eng) > Cc: ; > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded > > On Jul 6, 2013, at 12:15 PM, wrote: > >> First deploy, then tell the IETF about it, and let the IETF put the docu= mentation into >> the preferred 1970s ASCII format. > > Unless drone revoked RFC 2780, that's the wrong sequence. First develop = and test, then tell the IETF in a standards- track RFC, then get that RFC a= pproved, then get a transport number, then deploy. > > I don't mind general info about stuff in the area meetings, but feedback = requires participation, which requires a draft. And deployment of transport= s requires approved standards to get assigned numbers. > > Joe From touch@isi.edu Sat Jul 6 15:32:11 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7358321F9D01 for ; Sat, 6 Jul 2013 15:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8Yec0JiHHM2 for ; Sat, 6 Jul 2013 15:32:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B3ABD21F9B38 for ; Sat, 6 Jul 2013 15:32:06 -0700 (PDT) Received: from [192.168.1.97] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r66MUrhb012373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Jul 2013 15:31:03 -0700 (PDT) References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk> <04D8DC43-2A1F-446C-A14E-863A41219F0F@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE1@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494EE1@EXMB01CMS.surrey.ac.uk> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B350) From: Joe Touch Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Sat, 6 Jul 2013 15:30:49 -0700 To: "" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 22:32:11 -0000 On Jul 6, 2013, at 2:52 PM, wrote: >=20 > Few RFCs are standards track. But only those qualify for new transport numbers.=20 > IETF transport focuses on maintaining its existing standards; that's > my point. It's not really set up for experimental work not directly=20 > related to those standards. Early experimental work can come through the IRTF but new standards track tr= ansports can easily start in tsv wg. That wg isn't just for changes to exist= ing standards.=20 Joe >=20 > Lloyd Wood > http://sat-net.com/L.Wood/ >=20 >=20 > ________________________________________ > From: Joe Touch [touch@isi.edu] > Sent: 06 July 2013 19:33 > To: Wood L Dr (Electronic Eng) > Cc: > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded >=20 > And where in your sequence did a standard appear? Outside a wg? >=20 > On Jul 6, 2013, at 2:20 AM, wrote: >=20 >> Well, that's the wrong sequence, too. IANA can allocate numbers at draft s= tage long before RFC - as it did for Saratoga http://saratoga.sf.net >>=20 >> But even your sequence says 'tell the IETF', not 'participate in an IETF W= G with all the drones'. >>=20 >> Since QUIC is already deployed worldwide, I am reminded of King Canute. >>=20 >> Lloyd Wood >> http://sat-net.com/L.Wood/ >>=20 >>=20 >> ________________________________________ >> From: Joe Touch [touch@isi.edu] >> Sent: 06 July 2013 08:03 >> To: Wood L Dr (Electronic Eng) >> Cc: ; >> Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded >>=20 >> On Jul 6, 2013, at 12:15 PM, wrote: >>=20 >>> First deploy, then tell the IETF about it, and let the IETF put the docu= mentation into >>> the preferred 1970s ASCII format. >>=20 >> Unless drone revoked RFC 2780, that's the wrong sequence. First develop a= nd test, then tell the IETF in a standards- track RFC, then get that RFC app= roved, then get a transport number, then deploy. >>=20 >> I don't mind general info about stuff in the area meetings, but feedback r= equires participation, which requires a draft. And deployment of transports r= equires approved standards to get assigned numbers. >>=20 >> Joe From wes@mti-systems.com Sat Jul 6 19:10:46 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9E21F9A4A for ; Sat, 6 Jul 2013 19:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBaz3eqXfr3j for ; Sat, 6 Jul 2013 19:10:41 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 01FCA21F9956 for ; Sat, 6 Jul 2013 19:10:40 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r672AbtT013038 for ; Sat, 6 Jul 2013 22:10:37 -0400 Received: (qmail 20480 invoked by uid 0); 7 Jul 2013 02:10:37 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.133?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 7 Jul 2013 02:10:37 -0000 Message-ID: <51D8CE16.6060308@mti-systems.com> Date: Sat, 06 Jul 2013 22:10:30 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: l.wood@surrey.ac.uk Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk>, <04D8DC43-2A1F-446C-A14E-863A41219F0F@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE1@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494EE1@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 02:10:47 -0000 On 7/6/2013 5:52 PM, l.wood@surrey.ac.uk wrote: > > IETF transport focuses on maintaining its existing standards; that's > my point. It's not really set up for experimental work not directly > related to those standards. > I'm not really sure how TSV could be setup any better to do this type of work. It could be a matter of opinion how "directly related" the experimental work is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT is building on RTP ... but all are such significant developments that they can't be classed as simply "maintenance". In Berlin, TSV has 2 BoFs planned in Berlin which are not jst maintenance of existing standards (TCMTF and AQM). Clearly, there are also important existing protocols (TCP, SCTP, etc) that a lot of TSV energy goes into maintaining, but that's certainly not all that we do. The community focuses on what it chooses to, by individuals (and companies sponsoring them) investing time and energy into the WGs and drafts that they have shared interests in. For some experimental things, that can be difficult because it requires a critical mass, and people have to be willing to work together at whatever pace the group adapts. Larger groups will have slower paces. The hope is that we wind up with better specs, less flaws, and stronger interop between multiple codebases as a result of working together, and create a better Internet. Those are not the priority for every protocol development effort, and a lot of people have good reasons for doing things on their own. This does not signal a problem with the IETF. -- Wes Eddy MTI Systems From ietfdbh@comcast.net Sun Jul 7 10:53:08 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C2F11E80E8 for ; Sun, 7 Jul 2013 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.351 X-Spam-Level: X-Spam-Status: No, score=-100.351 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q38neEG5JQwf for ; Sun, 7 Jul 2013 10:53:03 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id D405611E80EA for ; Sun, 7 Jul 2013 10:52:59 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id xVCX1l0020QuhwU51VszH9; Sun, 07 Jul 2013 17:52:59 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta02.westchester.pa.mail.comcast.net with comcast id xVsy1l00N2yZEBF3NVsyN8; Sun, 07 Jul 2013 17:52:59 +0000 From: "ietfdbh" To: "'Wesley Eddy'" , References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk>, <04D8DC43-2A1F-446C-A14E-863A41219F0F@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE1@EXMB01CMS.surrey.ac.uk> <51D8CE16.6060308@mti-systems.com> In-Reply-To: <51D8CE16.6060308@mti-systems.com> Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded Date: Sun, 7 Jul 2013 13:52:30 -0400 Message-ID: <027401ce7b3a$c078b9a0$416a2ce0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3LqKzN4QJBbDJ1osACnOi5d6rhgIPQJMpAWeSrh4AgSfjIAOpmzb9AfUa2+0CQeud7gIYsMJxAe3obWUA/trVV5gBGw6g Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373219579; bh=Ql32OPCoPfzLNYyX0J9acRjY8pC4MgVgPbNY5mjjfYQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=I8p/b3mgdUx4mw5WR07oR7tz4PK0nKAg4kN8PL8bSW6Hsm/Pgh4g0Ls4xbqoMENDu T6ivI8KbQdefUs0Dwpp5rS9yoDXkrUngPPLkiiPUbG5ZJIZEMBQqwfwTxLJTDcgk9s //VDP78M/pJdkRYiNV6O8tsmQQsIlaWoeZDWgFR+atPv11rL4tyjJ0u5hg6uBGFRme xVkwkSTfDShEfS53M9WUn3qiY2WgqIMOZ9E4iQGAkiu1S2iiDF861zwHraf7VtSDcj SLlmZaMWtYw1XBbroR6gyHWpOK/4u/s2zkAXexRwbv49SkNH22dUHEDFjB5JEUlvnP EAHjnZ0C9XIEQ== Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 17:53:09 -0000 Hi, The IETF has always stressed a bottom-up approach, taking ideas and "running code" contributed by the community for new networking functionality, ranging from disruptive to purely maintenance, and deciding whether there was IETF consensus to work on standardizing the functionality. Typically contributed functionality is described in Internet-drafts so the IETF community can better understand the technology being proposed. This approach also helps to ensure the IETF doesn't become a forum for marketing press releases or other inappropriate usage of scarce IETF face-to-face time. Originally, BOFs were simply side meetings, often in bars, for an informal discussion of a new idea. There were no IPR rules, no requirements for an internet-draft first, and so on. Meeting in a bar allowed people to discuss *ideas* without the formality of requesting an IETF session. But there is a practical limit to the size of audience who can meet in a bar, to exchange ideas on bar-napkins. To supplement bar-bofs [rfc6771], the IETF standardized BOFs explicitly designed to allow the presentation of new ideas to the community, permitting larger audiences to gather in a room and have their meeting announced. BOFs, however, grew very quickly to meetings that might include food and alcohol provided by the idea proponents, and became more formal over time, with officially scheduled sessions, BOF chairs, microphones, and the whole shebang. Internet-drafts are typically required before a BOF session will be approved. Area directors realized there was a real downside to the increasing formality of BOFs - interesting ideas in the real world were not being brought into the IETF because the requirements to get a BOF session had become a hurdle. The IETF ignores what is happening around it in the real world at its own peril. Ignoring important new relevant technologies, especially potentially disruptive technologies, risks the IETF being "overtaken by events". If we want to stay relevant to the industry we support, we must be willing to listen to new ideas even if they do not come in the form of internet-drafts. Area meetings then became a venue for what some directors refer to as "mini-BOFs" - a larger audience than the bar-napkin discussions afford, but less formal than BOFs. An internet-draft would be nice so people knew where to look to find a discussion of the technology. However, the real goal is to get the industry to come into the IETF to talk about interesting and relevant technologies they have been working on outside the IETF. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On > Behalf Of Wesley Eddy > Sent: Saturday, July 06, 2013 10:11 PM > To: l.wood@surrey.ac.uk > Cc: tsv-area@ietf.org > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded > > On 7/6/2013 5:52 PM, l.wood@surrey.ac.uk wrote: > > > > IETF transport focuses on maintaining its existing standards; that's > > my point. It's not really set up for experimental work not directly > > related to those standards. > > > > > I'm not really sure how TSV could be setup any better to do this type of work. > It could be a matter of opinion how "directly related" the experimental work > is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT is > building on RTP ... but all are such significant developments that they can't be > classed as simply "maintenance". In Berlin, TSV has 2 BoFs planned in Berlin > which are not jst maintenance of existing standards (TCMTF and AQM). > Clearly, there are also important existing protocols (TCP, SCTP, etc) that a lot > of TSV energy goes into maintaining, but that's certainly not all that we do. > > The community focuses on what it chooses to, by individuals (and companies > sponsoring them) investing time and energy into the WGs and drafts that > they have shared interests in. For some experimental things, that can be > difficult because it requires a critical mass, and people have to be willing to > work together at whatever pace the group adapts. Larger groups will have > slower paces. > > The hope is that we wind up with better specs, less flaws, and stronger > interop between multiple codebases as a result of working together, and > create a better Internet. Those are not the priority for every protocol > development effort, and a lot of people have good reasons for doing things > on their own. This does not signal a problem with the IETF. > > -- > Wes Eddy > MTI Systems From spencerdawkins.ietf@gmail.com Sun Jul 7 20:39:44 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B6021F8FAF for ; Sun, 7 Jul 2013 20:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDfO0Jumv7fn for ; Sun, 7 Jul 2013 20:39:43 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 295BC21F8F09 for ; Sun, 7 Jul 2013 20:39:43 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so5056132obc.12 for ; Sun, 07 Jul 2013 20:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jgvVJjch1Ibutnh/HNEmJF2QcbqjRWgOGQIpTKoeih8=; b=LVTQ2XU16/LBPncQYmjp4yw4nmOYXufJTumoXWUzwBa1MG9QCC3ypJDlj+K2qMSImR +NcsxGRviUjTCBAjBgHKH4OhRpeyC13Dda81NkFoebB5+Ky/v/x1SUSISmzVls7pskaw BxZYwiN4OUytpgFthVkbHct1Ann2p3+8fDbBrpq3xNbMfpbsd/RWstnZJCukn+ptvjbK 093kUgeq6ZsRfFwY3/lFRrNIoB/f4ogz6YHvKyVKsyXz69cBlQwCI5Ih8SNsbOeOzUO9 Zcs4O1lW9g34mTLtQYfL5I+VXKCLiq84qPz1t+osb96gUvmApivMzsmaULnfsPEN/AxK Xe+w== X-Received: by 10.60.52.165 with SMTP id u5mr18757491oeo.15.1373254780614; Sun, 07 Jul 2013 20:39:40 -0700 (PDT) Received: from [192.168.1.77] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id rs4sm30761591obc.10.2013.07.07.20.39.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 20:39:39 -0700 (PDT) Message-ID: <51DA3477.9020303@gmail.com> Date: Sun, 07 Jul 2013 22:39:35 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ietfdbh Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded References: <51D51AB0.2030604@neclab.eu> <013501ce78c2$44ad9c20$ce08d460$@comcast.net> <51D61564.9070900@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EDE@EXMB01CMS.surrey.ac.uk> <8A556544-3427-4A17-A647-8380B1D62753@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE0@EXMB01CMS.surrey.ac.uk>, <04D8DC43-2A1F-446C-A14E-863A41219F0F@isi.edu> <290E20B455C66743BE178C5C84F12408223F494EE1@EXMB01CMS.surrey.ac.uk> <51D8CE16.6060308@mti-systems.com> <027401ce7b3a$c078b9a0$416a2ce0$@comcast.net> In-Reply-To: <027401ce7b3a$c078b9a0$416a2ce0$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 03:39:44 -0000 The notes I've read in this thread have been very helpful to me. Thank you for sharing. At this point, the only thing I'm obsessing about is that we get decent IPR declarations when IPR exists. Our BCPs define a contribution broadly enough to include presentations. The *IRTF* now has an IPR policy that's roughly equivalent to the IETF's policy; if people can't talk about research without disclosing, we should have the same stance for presentations on engineering topics. If the presenters are clear on that, I'm over the biggest hurdle. Spencer On 7/7/2013 12:52 PM, ietfdbh wrote: > Hi, > > The IETF has always stressed a bottom-up approach, taking ideas and "running > code" contributed by the community for new networking functionality, ranging > from disruptive to purely maintenance, and deciding whether there was IETF > consensus to work on standardizing the functionality. > > Typically contributed functionality is described in Internet-drafts so the > IETF community can better understand the technology being proposed. This > approach also helps to ensure the IETF doesn't become a forum for marketing > press releases or other inappropriate usage of scarce IETF face-to-face > time. > > Originally, BOFs were simply side meetings, often in bars, for an informal > discussion of a new idea. There were no IPR rules, no requirements for an > internet-draft first, and so on. Meeting in a bar allowed people to discuss > *ideas* without the formality of requesting an IETF session. But there is a > practical limit to the size of audience who can meet in a bar, to exchange > ideas on bar-napkins. > > To supplement bar-bofs [rfc6771], the IETF standardized BOFs explicitly > designed to allow the presentation of new ideas to the community, permitting > larger audiences to gather in a room and have their meeting announced. BOFs, > however, grew very quickly to meetings that might include food and alcohol > provided by the idea proponents, and became more formal over time, with > officially scheduled sessions, BOF chairs, microphones, and the whole > shebang. Internet-drafts are typically required before a BOF session will be > approved. > > Area directors realized there was a real downside to the increasing > formality of BOFs - interesting ideas in the real world were not being > brought into the IETF because the requirements to get a BOF session had > become a hurdle. The IETF ignores what is happening around it in the real > world at its own peril. Ignoring important new relevant technologies, > especially potentially disruptive technologies, risks the IETF being > "overtaken by events". > > If we want to stay relevant to the industry we support, we must be willing > to listen to new ideas even if they do not come in the form of > internet-drafts. Area meetings then became a venue for what some directors > refer to as "mini-BOFs" - a larger audience than the bar-napkin discussions > afford, but less formal than BOFs. An internet-draft would be nice so people > knew where to look to find a discussion of the technology. However, the real > goal is to get the industry to come into the IETF to talk about interesting > and relevant technologies they have been working on outside the IETF. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On >> Behalf Of Wesley Eddy >> Sent: Saturday, July 06, 2013 10:11 PM >> To: l.wood@surrey.ac.uk >> Cc: tsv-area@ietf.org >> Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded >> >> On 7/6/2013 5:52 PM, l.wood@surrey.ac.uk wrote: >>> IETF transport focuses on maintaining its existing standards; that's >>> my point. It's not really set up for experimental work not directly >>> related to those standards. >>> >> >> I'm not really sure how TSV could be setup any better to do this type of > work. >> It could be a matter of opinion how "directly related" the experimental > work >> is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT > is >> building on RTP ... but all are such significant developments that they > can't be >> classed as simply "maintenance". In Berlin, TSV has 2 BoFs planned in > Berlin >> which are not jst maintenance of existing standards (TCMTF and AQM). >> Clearly, there are also important existing protocols (TCP, SCTP, etc) that > a lot >> of TSV energy goes into maintaining, but that's certainly not all that we > do. >> The community focuses on what it chooses to, by individuals (and companies >> sponsoring them) investing time and energy into the WGs and drafts that >> they have shared interests in. For some experimental things, that can be >> difficult because it requires a critical mass, and people have to be > willing to >> work together at whatever pace the group adapts. Larger groups will have >> slower paces. >> >> The hope is that we wind up with better specs, less flaws, and stronger >> interop between multiple codebases as a result of working together, and >> create a better Internet. Those are not the priority for every protocol >> development effort, and a lot of people have good reasons for doing things >> on their own. This does not signal a problem with the IETF. >> >> -- >> Wes Eddy >> MTI Systems From swb@internet2.edu Mon Jul 8 05:38:16 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A355511E81F4 for ; Mon, 8 Jul 2013 05:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdaWmndGqcpn for ; Mon, 8 Jul 2013 05:38:10 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3611E81E8 for ; Mon, 8 Jul 2013 05:37:25 -0700 (PDT) Received: from mail77-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE021.bigfish.com (10.43.70.78) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 12:37:21 +0000 Received: from mail77-ch1 (localhost [127.0.0.1]) by mail77-ch1-R.bigfish.com (Postfix) with ESMTP id D21DA420097; Mon, 8 Jul 2013 12:37:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.149; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0810HT002.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: S0(zzbb2dI98dI1432Izz1f42h1d77h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275bhz2dh2a8h668h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received: from mail77-ch1 (localhost.localdomain [127.0.0.1]) by mail77-ch1 (MessageSwitch) id 137328704094848_19111; Mon, 8 Jul 2013 12:37:20 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail77-ch1.bigfish.com (Postfix) with ESMTP id 109E0440057; Mon, 8 Jul 2013 12:37:20 +0000 (UTC) Received: from CH1PRD0810HT002.namprd08.prod.outlook.com (157.56.245.149) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 12:37:18 +0000 Received: from CH1PRD0810MB395.namprd08.prod.outlook.com ([169.254.11.119]) by CH1PRD0810HT002.namprd08.prod.outlook.com ([10.255.145.165]) with mapi id 14.16.0329.000; Mon, 8 Jul 2013 12:37:17 +0000 From: Scott Brim To: Spencer Dawkins , ietfdbh Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Topic: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Index: AQHOeIKBOJG+XnguKkmt+W8/0U6V6JlUk4IAgAAMuoCAAJ6HAIABvkmAgAA/tQCAACZ1gIAAmmcAgAA3soCAAEf6AIABBzIAgACkB4CAAFMqAA== Date: Mon, 8 Jul 2013 12:37:17 +0000 Message-ID: In-Reply-To: <51DA3477.9020303@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.145.132] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: internet2.edu Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:38:16 -0000 T24gMDcvMDcvMTMgMjM6MzksICJTcGVuY2VyIERhd2tpbnMiIDxzcGVuY2VyZGF3a2lucy5pZXRm QGdtYWlsLmNvbT4NCmFsbGVnZWRseSB3cm90ZToNCg0KPlRoZSBub3RlcyBJJ3ZlIHJlYWQgaW4g dGhpcyB0aHJlYWQgaGF2ZSBiZWVuIHZlcnkgaGVscGZ1bCB0byBtZS4gVGhhbmsNCj55b3UgZm9y IHNoYXJpbmcuDQo+DQo+QXQgdGhpcyBwb2ludCwgdGhlIG9ubHkgdGhpbmcgSSdtIG9ic2Vzc2lu ZyBhYm91dCBpcyB0aGF0IHdlIGdldCBkZWNlbnQNCj5JUFIgZGVjbGFyYXRpb25zIHdoZW4gSVBS IGV4aXN0cy4gT3VyIEJDUHMgZGVmaW5lIGEgY29udHJpYnV0aW9uIGJyb2FkbHkNCj5lbm91Z2gg dG8gaW5jbHVkZSBwcmVzZW50YXRpb25zLiBUaGUgKklSVEYqIG5vdyBoYXMgYW4gSVBSIHBvbGlj eSB0aGF0J3MNCj5yb3VnaGx5IGVxdWl2YWxlbnQgdG8gdGhlIElFVEYncyBwb2xpY3k7IGlmIHBl b3BsZSBjYW4ndCB0YWxrIGFib3V0DQo+cmVzZWFyY2ggd2l0aG91dCBkaXNjbG9zaW5nLCB3ZSBz aG91bGQgaGF2ZSB0aGUgc2FtZSBzdGFuY2UgZm9yDQo+cHJlc2VudGF0aW9ucyBvbiBlbmdpbmVl cmluZyB0b3BpY3MuDQoNClNwZW5jZXIsIHdlIGRvbid0IG5lZWQgSVBSIGRpc2Nsb3N1cmVzIGlm IGEgY29udHJpYnV0aW9uIGlzIG5vdCBleHBlY3RlZA0KdG8gYWZmZWN0IElFVEYgb3V0cHV0cy4g ICJQYXJ0aWNpcGFudHMgd2hvIHJlYWxpemUgdGhhdCB0aGUgSVBSIHdpbGwgYmUgb3INCmhhcyBi ZWVuIGluY29ycG9yYXRlZCBpbnRvIGEgc3VibWlzc2lvbiB0byBiZSBwdWJsaXNoZWQgaW4gYW4g SW50ZXJuZXQNCkRyYWZ0LCBvciBpcyBzZXJpb3VzbHkgYmVpbmcgZGlzY3Vzc2VkIGluIGEgd29y a2luZyBncm91cCwgYXJlIHN0cm9uZ2x5DQplbmNvdXJhZ2VkIHRvIG1ha2UgYXQgbGVhc3QgYSBw cmVsaW1pbmFyeSBkaXNjbG9zdXJlLiINCg0K From l.wood@surrey.ac.uk Mon Jul 8 05:43:23 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E3611E81D9 for ; Mon, 8 Jul 2013 05:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=1.597, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpgBo5YtooG9 for ; Mon, 8 Jul 2013 05:43:18 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.108]) by ietfa.amsl.com (Postfix) with ESMTP id C219111E81CB for ; Mon, 8 Jul 2013 05:43:17 -0700 (PDT) Received: from [193.109.255.147:16418] by server-4.bemta-14.messagelabs.com id AB/84-27904-3E3BAD15; Mon, 08 Jul 2013 12:43:15 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-72.messagelabs.com!1373287349!11138302!22 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10125 invoked from network); 8 Jul 2013 12:43:15 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-12.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jul 2013 12:43:15 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 8 Jul 2013 13:43:10 +0100 From: To: , , Date: Mon, 8 Jul 2013 13:39:36 +0100 Subject: RE: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Topic: Draft agenda for the IETF-87 TSV Area meeting uploaded Thread-Index: AQHOeIKBOJG+XnguKkmt+W8/0U6V6JlUk4IAgAAMuoCAAJ6HAIABvkmAgAA/tQCAACZ1gIAAmmcAgAA3soCAAEf6AIABBzIAgACkB4CAAFMqAIAAQ7hK Message-ID: <290E20B455C66743BE178C5C84F12408223F494EEE@EXMB01CMS.surrey.ac.uk> References: <51DA3477.9020303@gmail.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:43:23 -0000 But if it's not expected to have any effect on IETF outputs, why bother pre= senting it at TSVAREA to the IETF? Oh wait, QUIC isn't in an internet-draft, so it won't have any effect on IE= TF outputs. We don't need IPR disclosures. We're good. Lloyd Wood http://sat-net.com/L.Wood/dtn/http-dtn has previously presented to TSVAREA to zero effect. ________________________________________ From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] On Behalf Of Sc= ott Brim [swb@internet2.edu] Sent: 08 July 2013 13:37 To: Spencer Dawkins; ietfdbh Cc: tsv-area@ietf.org Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded On 07/07/13 23:39, "Spencer Dawkins" allegedly wrote: >The notes I've read in this thread have been very helpful to me. Thank >you for sharing. > >At this point, the only thing I'm obsessing about is that we get decent >IPR declarations when IPR exists. Our BCPs define a contribution broadly >enough to include presentations. The *IRTF* now has an IPR policy that's >roughly equivalent to the IETF's policy; if people can't talk about >research without disclosing, we should have the same stance for >presentations on engineering topics. Spencer, we don't need IPR disclosures if a contribution is not expected to affect IETF outputs. "Participants who realize that the IPR will be or has been incorporated into a submission to be published in an Internet Draft, or is seriously being discussed in a working group, are strongly encouraged to make at least a preliminary disclosure." From spencerdawkins.ietf@gmail.com Mon Jul 8 08:10:23 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B1821F9A34 for ; Mon, 8 Jul 2013 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbfYsTiiQ2Ot for ; Mon, 8 Jul 2013 08:10:23 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 03E7021F9808 for ; Mon, 8 Jul 2013 08:10:22 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so4405485pbb.19 for ; Mon, 08 Jul 2013 08:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cexVT88hYdRswF8++jXp17k5ZddVyPrdKnjYCYtG7+4=; b=znSuGAAjxXizsWQ0Do8HGgdQ6ck7myPbcuYM2RKN7TRl4QYjoc8L6ImcG4k2/NAz9L 5848uZR/kpwvr0gEXbM6mjNlX2y1VfO0Gm/T6WUEq/pcToNa1lWryH9GjwcRA7KcNWjz smUi7QdrHl6z+xP856a3MAdevOcSKlejNjlDCBXVNUAD/Mh77YNuBlvvfS2Aqk338YLZ hi/nbacQjy0j9D9pD9fsIFTEVPzyE+piXLRJBxn+tY4pvdGoryOJIHj2RWxeNPhMH+Tu Y6/dz78RBs4J8Iof3K+35qx0KrDyXaX9hQ19eHywshxzgODrTXmiDISu4P9iqtDi9nQ6 kdyg== X-Received: by 10.66.144.170 with SMTP id sn10mr23607590pab.42.1373296222712; Mon, 08 Jul 2013 08:10:22 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id sz6sm24677016pab.5.2013.07.08.08.10.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 08:10:21 -0700 (PDT) Message-ID: <51DAD64E.7070800@gmail.com> Date: Mon, 08 Jul 2013 10:10:06 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: l.wood@surrey.ac.uk Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded References: <51DA3477.9020303@gmail.com>, <290E20B455C66743BE178C5C84F12408223F494EEE@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F12408223F494EEE@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:10:23 -0000 On 7/8/2013 7:39 AM, l.wood@surrey.ac.uk wrote: > But if it's not expected to have any effect on IETF outputs, why bother presenting it at TSVAREA to the IETF? FWIW, Martin and I have chatted privately about possible reasons to have a presentation about a technology which isn't described in a draft, in TSVAREA. I came away from that discussion thinking that it's really hard to know that an idea won't affect IETF outputs in the future. I wasn't there, but I believe a similar question came up most recently from the audience during a non-draft presentation to SAAG - "is there IPR on the fascinating topic you're presenting?" Without regard to anything else, what I heard was that the question pretty much derailed the conversation, because IETF participants require little prompting to hypothesize about IPR instead of talking about a technology. So, at least one reason for me to ask now, is to avoid someone else asking the same question in a roomful of people when we could be learning from someone who cared enough to share with us. Spencer p.s. Scott, I'm more than somewhat sympathetic to your point of view, but after the IRSG decided to require disclosures just in case someone contributed something in a research group that was interesting enough to take it to the IETF eventually, I'm having a hard time being less curious in what is, after all, an IETF working group. > Oh wait, QUIC isn't in an internet-draft, so it won't have any effect on IETF outputs. > > We don't need IPR disclosures. We're good. > > Lloyd Wood > http://sat-net.com/L.Wood/dtn/http-dtn > > has previously presented to TSVAREA to zero effect. > > ________________________________________ > From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] On Behalf Of Scott Brim [swb@internet2.edu] > Sent: 08 July 2013 13:37 > To: Spencer Dawkins; ietfdbh > Cc: tsv-area@ietf.org > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded > > On 07/07/13 23:39, "Spencer Dawkins" > allegedly wrote: > >> The notes I've read in this thread have been very helpful to me. Thank >> you for sharing. >> >> At this point, the only thing I'm obsessing about is that we get decent >> IPR declarations when IPR exists. Our BCPs define a contribution broadly >> enough to include presentations. The *IRTF* now has an IPR policy that's >> roughly equivalent to the IETF's policy; if people can't talk about >> research without disclosing, we should have the same stance for >> presentations on engineering topics. > Spencer, we don't need IPR disclosures if a contribution is not expected > to affect IETF outputs. "Participants who realize that the IPR will be or > has been incorporated into a submission to be published in an Internet > Draft, or is seriously being discussed in a working group, are strongly > encouraged to make at least a preliminary disclosure." > From jsaldana@unizar.es Thu Jul 11 02:19:24 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6521F9F58; Thu, 11 Jul 2013 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTWdOpxxTf-b; Thu, 11 Jul 2013 02:19:19 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id E758C21F9EFE; Thu, 11 Jul 2013 02:19:18 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r6B9JE4o010082; Thu, 11 Jul 2013 11:19:14 +0200 From: "Jose Saldana" To: Subject: I-D Action: draft-saldana-tsvwg-tcmtf-05.txt Date: Thu, 11 Jul 2013 11:19:16 +0200 Organization: Universidad de Zaragoza Message-ID: <003f01ce7e17$b7c80650$275812f0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5+F6MX4jDUXY/OS0Cr+ea+zD8mig== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, tsv-area@ietf.org, tsvwg@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:19:24 -0000 A new version of I-D, draft-saldana-tsvwg-tcmtf-05.txt has been successfully submitted by Jose Saldana and posted to the IETF repository. Filename: draft-saldana-tsvwg-tcmtf Revision: 05 Title: Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Creation date: 2013-07-11 Group: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-saldana-tsvwg-tcmtf-05.txt Status: http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf Htmlized: http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-tcmtf-05 Abstract: Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a method for improving the bandwidth utilization of network segments that carry multiple flows in parallel sharing a common path. The method combines standard protocols for header compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple flows are carried over that path. The amount of packets per second can also be reduced. This document describes the TCM-TF framework and the different options which can be used for each layer (header compression, multiplexing and tunneling). The IETF Secretariat From Martin.Stiemerling@neclab.eu Thu Jul 11 12:39:04 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DDC11E812C for ; Thu, 11 Jul 2013 12:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qyMHNG5w6MM for ; Thu, 11 Jul 2013 12:39:00 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8993E11E8114 for ; Thu, 11 Jul 2013 12:39:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E8BC1104A77 for ; Thu, 11 Jul 2013 21:38:25 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqNd68lnZQcM for ; Thu, 11 Jul 2013 21:38:25 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C9D88FFDCB for ; Thu, 11 Jul 2013 21:38:20 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 11 Jul 2013 21:36:50 +0200 Message-ID: <51DF09B8.2050506@neclab.eu> Date: Thu, 11 Jul 2013 21:38:32 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Subject: Feedback request: The desired expertise of a Transport Area Director Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:39:04 -0000 Hi all, The IESG makes a write-up about the desired expertise of Area Directors in general and also for each area. This write-up is sent to the NOMCOM. You can find the write-up for the last round here: https://www.ietf.org/group/nomcom/2012/iesg-requirements The desired expertise was also discussed during the Transport Area Open Meeting at the IETF-86 meeting in Orlando. Please check the meeting minutes for the feedback the community provided: http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea There is now a new write-up for the upcoming deliberations of the NOMCOM, taking the comments received in the IETF-86 area meeting into account: http://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise The general part, as well as the write-ups for the other areas, is available here: http://trac.tools.ietf.org/group/iesg/trac/wiki/DesiredExpertise Please note that these write-ups are reflecting the view of the IESG and not of the NOMCOM or the community at large. However, Spencer and I are requesting your feedback about the Transport Area Director part. Please send your feedback either to the TSV-Area list, directly to Spencer and/or me, or to the IESG until ***Thursday, 2013-07-18 10am EDT*** This is the deadline for the IESG to approve what the IESG sends to NOMCOM. You can always send feedback about the desired expertise to the NOMCOM! After that date/time, please send feedback about any of the IESG position descriptions to the NOMCOM. Your Transport ADs Spencer and Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From john@jlc.net Thu Jul 11 19:17:32 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8A021F9EE9 for ; Thu, 11 Jul 2013 19:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.902 X-Spam-Level: X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wJQgevqiLyJ for ; Thu, 11 Jul 2013 19:17:28 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AF27421F9ECA for ; Thu, 11 Jul 2013 19:17:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3516933C21; Thu, 11 Jul 2013 22:17:27 -0400 (EDT) Date: Thu, 11 Jul 2013 22:17:27 -0400 From: John Leslie To: Martin Stiemerling Subject: Re: Feedback request: The desired expertise of a Transport Area Director Message-ID: <20130712021727.GL18393@verdi> References: <51DF09B8.2050506@neclab.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51DF09B8.2050506@neclab.eu> User-Agent: Mutt/1.4.1i Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 02:17:32 -0000 Martin Stiemerling wrote: > > The IESG makes a write-up about the desired expertise of Area Directors > in general and also for each area. This write-up is sent to the NOMCOM. > > There is now a new write-up for the upcoming deliberations of the > NOMCOM, taking the comments received in the IETF-86 area meeting into > account: > http://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise >... > Please send your feedback either to the TSV-Area list, directly to > Spencer and/or me, or to the IESG until > > ***Thursday, 2013-07-18 10am EDT*** The IESG wants to finalize their input to NOMCOM on July 18. There will be an additional period for comments _after_ it goes to NOMCOM... But this is worth discussing on this list now. For at least the last four years, NOMCOM has had serious trouble finding candidates that meet the desired expertise. For now I'll concentrate on this paragraph: ] ] A Transport AD should have a broad understanding of core end-to-end ] transport topics such as congestion control, flow control, real-time ] transport protocols, NATs and firewalls, and related topics such as ] storage protocols. It is not necessarily important to be an expert ] in any of these, as it is much more important to be knowledgable in ] the principles of these transport topics, such as congestion control ] and congestoin management, Intserv and Diffserv. A Transport AD ] should have good relationships with the topic experts in the ] Transport area and also other areas, which in turn requires good ] soft skills. This is already an improvement over last year's version, which listed a number of specifics which I, at least, had suggested were no longer required or of limited duration. But I direct everyone's attention to David Harrington's message about the problems he faced as Transport AD: http://www.ietf.org/mail-archive/web/ietf/current/msg77860.html The whole post is well worth reading, but I particularly note: ] ] You'll need enough understanding of the TSV issues to be able to ] spot bad transport-related decisions in documents coming from ] elsewhere in the IETF. You (and your co-AD) are effectively the ] reviewer of last resort for TSV issues. If you don't understand ] control loops, congestion control techniques, etc., you will ] NEED to rely on your directorate for assistance in this role. I suggest that "understand control loops" deserves specific mention in the desired expertise. Personally, I'd add "hysteresis in control loops". "Congestion control techniques" is definitely something the NOMCOM should look for candidates to understand. But to me, that wording is open-ended; and we don't need an expert on all such techniques. I think we need someone who understands the basic "additive increase; multiplicative decrease" mechanism of vanilla TCP; but that other _control_ techniques are too varied -- a Transport AD will need to have Directorate members help with those. I'd like to see some mention of understanding "congestion signaling". We've evolved quite a bit from the days when packet drop was the only congestion signal. ECN is in active, if limited, use. There are a number of delay-based indicators now: mostly inferring queueing delay from transit time, but recently actually measuring time-in-queue (such as CoDel and PIE). All of these signals involve trade-offs, if not outright guessing; so we shouldn't look for expert-level understanding, but a basic understanding of congestion signals seems important to me. David Harrington dwells at length on his experience with the Transport Directorate. We might tweak the last sentence of the paragraph I quoted from the desired expertise: " " A Transport AD should have good relationships with the topic " experts in the Transport area and also other areas, which in turn " requires good soft skills. to indicate actual management skills in keeping the Directorate functioning well. As for the other items listed in the desired expertise: " " topics such as congestion control, flow control, real-time " transport protocols, NATs and firewalls, and related topics " such as storage protocols. I'd really prefer that others comment first on what level of understanding we should ask for. They are all interesting (though I personally regard NATs as damage to route around), but I don't know how essential they are to a Transport AD. Recall that we _need_ to make the NOMCOM's job possible! -- John Leslie From michael.scharf@alcatel-lucent.com Mon Jul 15 08:28:06 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C261511E812C for ; Mon, 15 Jul 2013 08:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDwvdYVTwPT6 for ; Mon, 15 Jul 2013 08:28:01 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5905C11E80FB for ; Mon, 15 Jul 2013 08:28:01 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6FFRwRu004305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jul 2013 10:28:00 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6FFRw2q010967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 17:27:58 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 15 Jul 2013 17:27:58 +0200 From: "Scharf, Michael (Michael)" To: Martin Stiemerling , "tsv-area@ietf.org" Subject: RE: Feedback request: The desired expertise of a Transport Area Director Thread-Topic: Feedback request: The desired expertise of a Transport Area Director Thread-Index: AQHOfm5RbvwnhLsIOE6fQes6pED725llz00g Date: Mon, 15 Jul 2013 15:27:57 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51DF09B8.2050506@neclab.eu> In-Reply-To: <51DF09B8.2050506@neclab.eu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:28:06 -0000 > There is now a new write-up for the upcoming deliberations of=20 > the NOMCOM, taking the comments received in the IETF-86 area=20 > meeting into > account: > http://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise For what it is worth... > The Transport Area works on mechanisms related to end-to-end data tran= sport as well as technologies for network storage and peer-to-peer applicat= ions. Transport protocols support Internet applications and services that e= xchange potentially large volumes of traffic at potentially high bandwidths= . I wonder if the first sentence indeed includes CDNI, IPPM, and possibly new= AQM work? For instance, what about "The Transport Area works on end-to-end transport = protocols, mechanisms related to performance and congestion control, as wel= l as technologies for network storage, content delivery, and peer-to-peer a= pplications" ? > The Transport Area intersects most frequently with Internet Area, the = Applications Area, the RAI Area, the Security Area, and the IRTF ICCRG rese= arch groups. Cross-area expertise in any of those Areas would be particular= ly useful. s/IRTF ICCRG research groups/IRTF research groups such as ICCRG/ ? > Current and new transport work includes congestion signaling and repor= ting, QoS and reservation signaling, DiffServ? and congestion control for u= nresponsive flows, NAT regularization and specification, storage protocols = for the Internet, peer-to-peer streaming, performance metrics for Internet = paths, experimentation with congestion control schemes developed in the IRT= F, multipath extensions to existing transport protocols, and congestion con= trol algorithms for interactive real time media. Well, TCPM is currently pretty busy with "extensions to existing transport = protocols". And not all of them are about congestion signaling or multipath= ;) > A Transport AD should have a broad understanding of core end-to-end tr= ansport topics such as congestion control, flow control, real-time transpor= t protocols, NATs and firewalls, and related topics such as storage protoco= ls. It is not necessarily important to be an expert in any of these, as it = is much more important to be knowledgable in the principles of these transp= ort topics, such as congestion control and congestoin management, Intserv a= nd Diffserv. A Transport AD should have good relationships with the topic e= xperts in the Transport area and also other areas, which in turn requires g= ood soft skills. At least TCPM also has to be aware of middleboxes other than NATs and firew= alls, including gateways that mess up TCP options, all kinds of load balanc= ers, transparent caches, etc. For instance: s/NATs and firewalls/middleboxe= s such as NATs and firewalls/ ? I also have the impression that TSV work is often related to operation syst= em design and implementation issues. There is a lot of literature on the pr= inciples of congestion control. Unfortunately, there is much less literatur= e that provides insight whether a given RFC can indeed be implemented robus= tly in a production TCP/IP stack or a real network element... Editorial nit: s/congestoin/congestion/ Michael > Some topics in transport mechanisms have strong ties to the research c= ommunity, therefore some research background can be very helpful. > > Together, the two Transport ADs are expected to understand how transpo= rt technologies (layer 4) interact with IP layer technologies and protocols= (layer 3) technologies, and with the end-to-end aspects of various applica= tions and application-layer protocols (layer 7). From john@jlc.net Mon Jul 15 09:17:29 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC16011E8113 for ; Mon, 15 Jul 2013 09:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.181 X-Spam-Level: X-Spam-Status: No, score=-106.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeuAU0-bpCsr for ; Mon, 15 Jul 2013 09:17:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 31E4221F90C3 for ; Mon, 15 Jul 2013 09:17:23 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9561B33C29; Mon, 15 Jul 2013 12:17:13 -0400 (EDT) Date: Mon, 15 Jul 2013 12:17:13 -0400 From: John Leslie To: "Scharf, Michael (Michael)" Subject: Re: Feedback request: The desired expertise of a Transport Area Director Message-ID: <20130715161713.GA5411@verdi> References: <51DF09B8.2050506@neclab.eu> <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:17:30 -0000 Scharf, Michael (Michael) wrote: > [Martin Stiemerling wrote:] >> >> http://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise >... >> The Transport Area works on... > > what about "The Transport Area works on end-to-end transport protocols, > mechanisms related to performance and congestion control, as well as > technologies for network storage, content delivery, and peer-to-peer > applications" ? This strikes me as reasonable. >> The Transport Area intersects most frequently with Internet Area, >> the Applications Area, the RAI Area, the Security Area, and the > IRTF ICCRG research groups. Cross-area expertise in any of those > Areas would be particularly useful. > > s/IRTF ICCRG research groups/IRTF research groups such as ICCRG/ ? I don't see the need for this. ICCRG is almost joined-at-the-hip, but interaction with other IRTF groups is the exception. >> Current and new transport work includes... > > TCPM is currently pretty busy with "extensions to existing transport > protocols". And not all of them are about congestion signaling or > multipath ;) True; but this is not text we expect to revise every year. TSV ADs are not expected to have expertise in the work of _every_ TSV WG. >> A Transport AD should have a broad understanding... > > At least TCPM also has to be aware of middleboxes other than NATs > and firewalls, including gateways that mess up TCP options, all kinds > of load balancers, transparent caches, etc. The WG needs such expertise, but does the AD need it? > For instance: s/NATs and firewalls/middleboxes such as NATs and > firewalls/ ? For myself, I'd prefer not to require middlebox expertise of TSV ADs. > I also have the impression that TSV work is often related to operation > system design and implementation issues. There is a lot of literature > on the principles of congestion control. Unfortunately, there is much > less literature that provides insight whether a given RFC can indeed > be implemented robustly in a production TCP/IP stack or a real network > element... True, but we need to make the NOMCOM's job possible. IMHO, we shouldn't ask TSV ADs to be experts on implementation issues. -- John Leslie From michael.scharf@alcatel-lucent.com Mon Jul 15 09:42:28 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A711E8108 for ; Mon, 15 Jul 2013 09:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwuivO1HqW6H for ; Mon, 15 Jul 2013 09:42:21 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8F25D11E80AD for ; Mon, 15 Jul 2013 09:42:21 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6FGgIIt000873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jul 2013 11:42:20 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6FGgHUb021332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 18:42:17 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 15 Jul 2013 18:42:17 +0200 From: "Scharf, Michael (Michael)" To: John Leslie Subject: RE: Feedback request: The desired expertise of a Transport Area Director Thread-Topic: Feedback request: The desired expertise of a Transport Area Director Thread-Index: AQHOgXbNLiCnOTpyXkuuYWKbkEpv4Zll60WQ Date: Mon, 15 Jul 2013 16:42:16 +0000 Message-ID: <655C07320163294895BBADA28372AF5D06958A@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <51DF09B8.2050506@neclab.eu> <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130715161713.GA5411@verdi> In-Reply-To: <20130715161713.GA5411@verdi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:42:28 -0000 > >> The Transport Area intersects most frequently with=20 > Internet Area, the=20 > >> Applications Area, the RAI Area, the Security Area, and the > > IRTF ICCRG research groups. Cross-area expertise in any of=20 > those Areas=20 > > would be particularly useful. > >=20 > > s/IRTF ICCRG research groups/IRTF research groups such as ICCRG/ ? >=20 > I don't see the need for this. ICCRG is almost=20 > joined-at-the-hip, but interaction with other IRTF groups is=20 > the exception. these days there is also ICNRG, which has "Congestion control, QoS approach= es" in its charter, and there are recent coding discussions in IRTF, which = are not entirely unrelated to TCP(M) as well... This is why I could imagine= that a future AD might have to interact with RGs other than ICCRG, too. > >> Current and new transport work includes... > >=20 > > TCPM is currently pretty busy with "extensions to existing=20 > transport=20 > > protocols". And not all of them are about congestion signaling or=20 > > multipath ;) >=20 > True; but this is not text we expect to revise every year.=20 > TSV ADs are not expected to have expertise in the work of=20 > _every_ TSV WG. True, but "extensions to existing transport protocols" is more generic than= any specific extension that is this year's hype topic of the community. > >> A Transport AD should have a broad understanding... > >=20 > > At least TCPM also has to be aware of middleboxes other=20 > than NATs and=20 > > firewalls, including gateways that mess up TCP options, all=20 > kinds of=20 > > load balancers, transparent caches, etc. >=20 > The WG needs such expertise, but does the AD need it? >=20 > > For instance: s/NATs and firewalls/middleboxes such as NATs and=20 > > firewalls/ ? >=20 > For myself, I'd prefer not to require middlebox expertise=20 > of TSV ADs. > > > I also have the impression that TSV work is often related=20 > to operation=20 > > system design and implementation issues. There is a lot of=20 > literature=20 > > on the principles of congestion control. Unfortunately,=20 > there is much=20 > > less literature that provides insight whether a given RFC=20 > can indeed=20 > > be implemented robustly in a production TCP/IP stack or a=20 > real network=20 > > element... >=20 > True, but we need to make the NOMCOM's job possible. IMHO,=20 > we shouldn't ask TSV ADs to be experts on implementation issues. I have not said that we need an "expert". Those may be rare, indeed. Michael From touch@isi.edu Mon Jul 15 09:52:07 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E4611E811B for ; Mon, 15 Jul 2013 09:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggv1UKsdgOx8 for ; Mon, 15 Jul 2013 09:51:51 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4284521E80E0 for ; Mon, 15 Jul 2013 09:51:12 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r6FGojoL013179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 09:50:45 -0700 (PDT) Message-ID: <51E42864.7060601@isi.edu> Date: Mon, 15 Jul 2013 09:50:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" Subject: Re: Feedback request: The desired expertise of a Transport Area Director References: <51DF09B8.2050506@neclab.eu> <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130715161713.GA5411@verdi> <655C07320163294895BBADA28372AF5D06958A@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D06958A@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:52:07 -0000 FWIW, I don't think transport == congestion control. There are a lot of other issues in connection semantics, service IDs, etc. that are integral to the transport layer which are equally critical. And I don't think a transport AD needs to be an expert on this, but they cannot rely on TSVDIR to point out key issues or concerns either; TSVDIR isn't on every IESG telechat, nor attending every IESG meeting at the IETF. TSVDIR aren't "guide dogs" for the (transport-)blind. ;-) We can help dig into details, but if the AD doesn't know to put the brakes on or raise an issue, by the time we get a doc it will be far too late. Joe From spencerdawkins.ietf@gmail.com Mon Jul 15 10:19:02 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B674F11E8138 for ; Mon, 15 Jul 2013 10:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+CMzHcL5rAp for ; Mon, 15 Jul 2013 10:19:02 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 66FE111E80AD for ; Mon, 15 Jul 2013 10:19:00 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n9so15872623oag.22 for ; Mon, 15 Jul 2013 10:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IZtJ/N0g7YtmhGPpHggSjyjrtTzZsO190ch7XMfl9S0=; b=0o4IeHuUBtteAKBv1msOBVHN1GoHhoiUcRpWuCMlGWBAmUqwLoyk2jIHNpgQh+sWZe t/lS6xVObsKoubn7aiXDIXdOKIaxctKO1OdPROYI1uQ6Zb/XRQJEK8g8pQSvoDUkfLeZ UX4B++9EWILNhig6BZdKg/hmxgJQwQfOeRUnEQm7XAOVbWdS1QCFtjiVHEq2qqORxCTs GtEw/6jbeg6s78ZSNPWlMmyUcW/OSp40V2Mi1xsBtkzq6pHFDdtGTlEuqyrdVDty6ddj MIE/SNjaeqpoPzjm6gAQ6LIpeLZydi9IOn8bw2YVe2nO4j1j25Hnky/lg4J33kyTiM5T sQiA== X-Received: by 10.60.160.194 with SMTP id xm2mr44900624oeb.82.1373908738954; Mon, 15 Jul 2013 10:18:58 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id hm1sm68918271obb.9.2013.07.15.10.18.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 10:18:58 -0700 (PDT) Message-ID: <51E42EFD.6060805@gmail.com> Date: Mon, 15 Jul 2013 12:18:53 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Leslie Subject: Re: Feedback request: The desired expertise of a Transport Area Director References: <51DF09B8.2050506@neclab.eu> <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130715161713.GA5411@verdi> In-Reply-To: <20130715161713.GA5411@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:19:02 -0000 On 7/15/2013 11:17 AM, John Leslie wrote: I might have opinions about the details, but want to strongly encourage people to take John's words to heart: "True, but we need to make the NOMCOM's job possible." What I'd like to see, is a description that some reasonable number of nominees are willing to be considered against. If some willing nominees have additional areas of expertise and experience that would be helpful for a TSV AD, great -and please tell the Nomcom that. But Nomcom need to start with a list of willing nominees that they can ask for feedback on. Spencer > Scharf, Michael (Michael) wrote: >> [Martin Stiemerling wrote:] >>> http://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise >> ... >>> The Transport Area works on... >> what about "The Transport Area works on end-to-end transport protocols, >> mechanisms related to performance and congestion control, as well as >> technologies for network storage, content delivery, and peer-to-peer >> applications" ? > This strikes me as reasonable. > >>> The Transport Area intersects most frequently with Internet Area, >>> the Applications Area, the RAI Area, the Security Area, and the >> IRTF ICCRG research groups. Cross-area expertise in any of those >> Areas would be particularly useful. >> >> s/IRTF ICCRG research groups/IRTF research groups such as ICCRG/ ? > I don't see the need for this. ICCRG is almost joined-at-the-hip, > but interaction with other IRTF groups is the exception. > >>> Current and new transport work includes... >> TCPM is currently pretty busy with "extensions to existing transport >> protocols". And not all of them are about congestion signaling or >> multipath ;) > True; but this is not text we expect to revise every year. TSV ADs > are not expected to have expertise in the work of _every_ TSV WG. > >>> A Transport AD should have a broad understanding... >> At least TCPM also has to be aware of middleboxes other than NATs >> and firewalls, including gateways that mess up TCP options, all kinds >> of load balancers, transparent caches, etc. > The WG needs such expertise, but does the AD need it? > >> For instance: s/NATs and firewalls/middleboxes such as NATs and >> firewalls/ ? > For myself, I'd prefer not to require middlebox expertise of TSV ADs. > >> I also have the impression that TSV work is often related to operation >> system design and implementation issues. There is a lot of literature >> on the principles of congestion control. Unfortunately, there is much >> less literature that provides insight whether a given RFC can indeed >> be implemented robustly in a production TCP/IP stack or a real network >> element... > True, but we need to make the NOMCOM's job possible. IMHO, we > shouldn't ask TSV ADs to be experts on implementation issues. > > -- > John Leslie From gettysjim@gmail.com Mon Jul 15 10:42:46 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A6521E80C6 for ; Mon, 15 Jul 2013 10:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ7Z1B0JeaTq for ; Mon, 15 Jul 2013 10:42:45 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 41B8511E80DC for ; Mon, 15 Jul 2013 10:42:45 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so16126227oag.32 for ; Mon, 15 Jul 2013 10:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+PmPEWlRyZ+5rd9Rhbh7WCOz+kmhnccIrWqiN/3Q9FA=; b=IAL0/XQIWxaRCr7MfYhy9t9vOLvKPpyAs9E0p3ViwfAGjNO+CuTB4AgSFYrNBsxcSI ASmnoLJyfU0+HyvsAdx6ZCdTPR93WVl+Z9u981LLi2vFcNpVTSRgAbH7Wo6ug5BPVziH kB71DWchdG7g4CXB+7Nxnx6e7tw4YZ4k/AwdZjJ+HgLSO9yDEbIf/uJYFq5W60x0MtqU Vnt46AHcJb7HVjeXCtGtbNoViO5y1BY9xmeFU3T/nxNL7R8n4l/+zNNpZl64p36Bisqe N3KacHh6emXchrxmlcFbKiTs9Zte2NyQdFHpPQig80E4Xp/4XZGyy/cVku+YjZVasTDf iXxQ== MIME-Version: 1.0 X-Received: by 10.182.27.102 with SMTP id s6mr42684113obg.42.1373910164716; Mon, 15 Jul 2013 10:42:44 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.144.67 with HTTP; Mon, 15 Jul 2013 10:42:44 -0700 (PDT) In-Reply-To: <51E42864.7060601@isi.edu> References: <51DF09B8.2050506@neclab.eu> <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130715161713.GA5411@verdi> <655C07320163294895BBADA28372AF5D06958A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <51E42864.7060601@isi.edu> Date: Mon, 15 Jul 2013 13:42:44 -0400 X-Google-Sender-Auth: BLf3NgVV24rqmlDKVVUumTXEpDs Message-ID: Subject: Re: Feedback request: The desired expertise of a Transport Area Director From: Jim Gettys To: Joe Touch Content-Type: multipart/alternative; boundary=089e01184c8c52412404e19063fd Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:42:46 -0000 --089e01184c8c52412404e19063fd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 15, 2013 at 12:50 PM, Joe Touch wrote: > FWIW, I don't think transport == congestion control. > Joe is exactly correct about this. > > There are a lot of other issues in connection semantics, service IDs, etc. > that are integral to the transport layer which are equally critical. > Another example, a large part of fq_codel's gains are over the sort of flow queuing it does, rather than congestion control. Our experience is congestion control is necessary, but not sufficient to deal with bufferbloat (see my recent blog article at: http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/ ). > > And I don't think a transport AD needs to be an expert on this, but they > cannot rely on TSVDIR to point out key issues or concerns either; TSVDIR > isn't on every IESG telechat, nor attending every IESG meeting at the IETF. > > TSVDIR aren't "guide dogs" for the (transport-)blind. ;-) > > We can help dig into details, but if the AD doesn't know to put the brakes > on or raise an issue, by the time we get a doc it will be far too late. I don't think the IETF can find people who know everything in depth (the person doesn't exist, probably); but nodding familiarity with a wide range of the issues is desirable. - Jim > > Joe > > --089e01184c8c52412404e19063fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon= , Jul 15, 2013 at 12:50 PM, Joe Touch <touch@isi.edu> wrote:
FWIW, I don't think transport =3D=3D congestion contro= l.

Joe is exactly correct about this.

There are a lot of other issues in connection semantics, service IDs, etc. = that are integral to the transport layer which are equally critical.

Another example, a large part of fq_codel's gains are over the sort of = flow queuing it does, rather than congestion control. Our experience is con= gestion control is necessary, but not sufficient to deal with bufferbloat (= see my recent blog article at:
http://gettys.wordpress.com/2013/07/10/low-latency-re= quires-smart-queuing-traditional-aqm-is-not-enough/).


And I don't think a transport AD needs to be an expert on this, but the= y cannot rely on TSVDIR to point out key issues or concerns either; TSVDIR = isn't on every IESG telechat, nor attending every IESG meeting at the I= ETF.

TSVDIR aren't "guide dogs" for the (transport-)blind. ;-)

We can help dig into details, but if the AD doesn't know to put the bra= kes on or raise an issue, by the time we get a doc it will be far too late.=

I don't think the IETF can find people who know everything in depth (th= e person doesn't exist, probably); but nodding familiarity with a wide = range of the issues is desirable.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim



Joe



--089e01184c8c52412404e19063fd-- From touch@isi.edu Mon Jul 15 10:50:23 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833E321E8108 for ; Mon, 15 Jul 2013 10:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7gkUePk8yBd for ; Mon, 15 Jul 2013 10:50:17 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9F621E8104 for ; Mon, 15 Jul 2013 10:50:16 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r6FHnDK3009170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 10:49:13 -0700 (PDT) Message-ID: <51E43619.2080904@isi.edu> Date: Mon, 15 Jul 2013 10:49:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jim Gettys Subject: Re: Feedback request: The desired expertise of a Transport Area Director References: <51DF09B8.2050506@neclab.eu> <655C07320163294895BBADA28372AF5D0692CD@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130715161713.GA5411@verdi> <655C07320163294895BBADA28372AF5D06958A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <51E42864.7060601@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:50:23 -0000 On 7/15/2013 10:42 AM, Jim Gettys wrote: ... > I don't think the IETF can find people who know everything in depth (the > person doesn't exist, probably); but nodding familiarity with a wide > range of the issues is desirable. > - Jim IMO, the paucity of candidates isn't just due to depth or breadth of knowledge. The intersection of the following is vanishingly small: - deep knowledge about cong control - deep knowledge about non-CC transport issues - supported to participate in the IETF - supported to travel to IETF meetings - willing to serve as AD Joe From david.black@emc.com Mon Jul 15 21:45:55 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF61021F9C4C for ; Mon, 15 Jul 2013 21:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eh2Gy3isYbG for ; Mon, 15 Jul 2013 21:45:49 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEA321F9AE7 for ; Mon, 15 Jul 2013 21:45:43 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6G4jf5x024857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 00:45:41 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 16 Jul 2013 00:45:32 -0400 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6G4jUXd006047; Tue, 16 Jul 2013 00:45:31 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Tue, 16 Jul 2013 00:45:30 -0400 From: "Black, David" To: Martin Stiemerling , "spencerdawkins.ietf@gmail.com" , "tsv-area@ietf.org" Date: Tue, 16 Jul 2013 00:45:28 -0400 Subject: RE: Feedback request: The desired expertise of a Transport Area Director Thread-Topic: Feedback request: The desired expertise of a Transport Area Director Thread-Index: Ac5+bl4v9NxnFhlKRnKou5ZwISDrLgDaWt/A Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> References: <51DF09B8.2050506@neclab.eu> In-Reply-To: <51DF09B8.2050506@neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 04:45:55 -0000 Spencer Dawkins writes: > I might have opinions about the details, but want to strongly encourage=20 > people to take John's words to heart: > > "True, but we need to make the NOMCOM's job possible." > > What I'd like to see, is a description that some reasonable number of=20 > nominees are willing to be considered against. If some willing nominees= =20 > have additional areas of expertise and experience that would be helpful=20 > for a TSV AD, great -and please tell the Nomcom that. But Nomcom need to= =20 > start with a list of willing nominees that they can ask for feedback on. I guess I ought to introduce myself, although I see that Dave Harrington's already gotten that off to a fine start in his description of his experienc= es as a TSV AD ... TSV has responsibility for storage protocols that need to operate over the Internet. These include NFS, and Internet interfaces for SCSI and Fibre Channel. All of these were developed elsewhere. Sun, of course, developed NFS and donated version 4 for standardization. SCSI and Fiber Channel are standardized by other SDOs, and we develop the interfaces to the Internet (iSCSI, FCIP, etc.), and provide feedback to the SCSI and FC SDOs. The IET= F standards for these run in the 300-page document range, and are largely unrelated to other IETF work. The chairs and the editors really understand their stuff, and TSV ADs can generally just "let them run" - until they submit their 300-page documents for IESG review. That sure sounds like it includes me, especially as I just asked Martin to (finally) send the 300+ page storm WG draft that consolidates and revises the iSCSI specs off to the RFC Editor ;-). I've also done quite a bit of other transport work, including QoS and congestion control (RFCs in both topic areas), plus the things I ride herd on as a tsvwg chair, as well as having multiple published RFCs in other IETF areas, e.g., Security. So, looking at the description (which I agree is already much improved over last year's), with an eye to how it fits me, the following two paragraphs appear to be the core of the matter - description of expected technical background/expertise: ----------------------- Current and new transport work includes congestion signaling and report= ing, QoS and reservation signaling, DiffServ? and congestion control for un= responsive flows, NAT regularization and specification, storage protocols f= or the Internet, peer-to-peer streaming, performance metrics for Internet p= aths, experimentation with congestion control schemes developed in the IRTF= , multipath extensions to existing transport protocols, and congestion cont= rol algorithms for interactive real time media. A Transport AD should have a broad understanding of core end-to-end tra= nsport topics such as congestion control, flow control, real-time transport= protocols, NATs and firewalls, and related topics such as storage protocol= s. It is not necessarily important to be an expert in any of these, as it i= s much more important to be knowledgeable in the principles of these transp= ort topics, such as congestion control and congestion management, Intserv a= nd Diffserv. A Transport AD should have good relationships with the topic e= xperts in the Transport area and also other areas, which in turn requires g= ood soft skills. ----------------------- The first paragraph is scary - I see ten listed areas of activity, about half of which I can reasonably claim some expertise in. As John Leslie noted: > TSV ADs are not expected to have expertise in the work of _every_ TSV WG. The second paragraph is much better, so I'd suggest adding a disclaimer sentence at the end of the first paragraph to capture John's point and help focus attention on the second paragraph. For example: Transport ADs are not expected to be experts on all or even most of these topics, but rather to work well with the Transport Area participants who are, and to have enough familiarity to exercise their own good judgmen= t about what should be done and why. In the second paragraph, I foresee problems with "and related topics such as storage protocols". While I fit those words rather well ;-), I'm a bit unusual in that regard - Dave Harrington's comment (quoted above) on storage protocols is apt: The IETF standards for these ... are largely unrelated to other IETF work. The [storage] chairs and the editors really understand their stuff, and TSV ADs can generally just "let them run". As I said in the tsvarea meeting in Orlando, I've never had to turn any of the many TSV ADs whom I've worked with into SCSI, Fibre Channel or storage experts - both they and the storage communities in the WGs that I've chaire= d are better off for that not having been necessary. I might change those words to "and related topics such as application use of transport protocols= ". That would involve considerations around topics such as head-of-line blocking and multiple parallel transport connections - that overall topic area applies to transport-related issues in WGs such as core and httpbis. Thanks, --David p.s. I'd include Diffserv in the description, as there is enough active diffserv-related work, at least at the moment. > -----Original Message----- > From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On Beh= alf > Of Martin Stiemerling > Sent: Thursday, July 11, 2013 3:39 PM > To: tsv-area@ietf.org > Subject: Feedback request: The desired expertise of a Transport Area Dire= ctor >=20 > Hi all, >=20 > The IESG makes a write-up about the desired expertise of Area Directors > in general and also for each area. This write-up is sent to the NOMCOM. >=20 > You can find the write-up for the last round here: > https://www.ietf.org/group/nomcom/2012/iesg-requirements >=20 >=20 > The desired expertise was also discussed during the Transport Area Open > Meeting at the IETF-86 meeting in Orlando. Please check the meeting > minutes for the feedback the community provided: > http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea >=20 >=20 > There is now a new write-up for the upcoming deliberations of the > NOMCOM, taking the comments received in the IETF-86 area meeting into > account: > http://trac.tools.ietf.org/group/iesg/trac/wiki/TransportExpertise >=20 >=20 > The general part, as well as the write-ups for the other areas, is > available here: > http://trac.tools.ietf.org/group/iesg/trac/wiki/DesiredExpertise >=20 >=20 > Please note that these write-ups are reflecting the view of the IESG and > not of the NOMCOM or the community at large. >=20 >=20 > However, Spencer and I are requesting your feedback about the Transport > Area Director part. >=20 > Please send your feedback either to the TSV-Area list, directly to > Spencer and/or me, or to the IESG until >=20 > ***Thursday, 2013-07-18 10am EDT*** >=20 > This is the deadline for the IESG to approve what the IESG sends to NOMCO= M. >=20 > You can always send feedback about the desired expertise to the NOMCOM! > After that date/time, please send feedback about any of the IESG > position descriptions to the NOMCOM. >=20 > Your Transport ADs >=20 > Spencer and Martin >=20 > -- > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 From spencerdawkins.ietf@gmail.com Tue Jul 16 13:52:15 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98A211E80FE for ; Tue, 16 Jul 2013 13:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnlmGk7aRYta for ; Tue, 16 Jul 2013 13:52:15 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7C82611E80F4 for ; Tue, 16 Jul 2013 13:52:05 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so1109710pbb.22 for ; Tue, 16 Jul 2013 13:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=q2HyWZTRHhbJPeOePGMHWha2jWj3TOLpXt3v97LjtYk=; b=z5zsDIhrwI8SEdhWp+lVTSGCfFg1uDhHkXhGy5I8tmaIhKMSbRGRZosdbXQ1l/ssel wJctlcLmjVv7ZZgnXdvmv1CYbYAdpLG562jy4DZdotpoDngxl45TgVJ4BF6YTD+okDly 23VHkOYlduklOzgEjIQaFwNn//8nDd3BmXQkCmj6efb2QFS+NIF+uucF48twxjTsTR46 BU+ejXB8BFux8+ZUML3g3IrvIWMzoXJx6pKZ+ji0gjdgmbXMAhTtjm7fcGu0rR53gFwU ZRblvW/o7JbqvjWyBs61ouVGTDsTyCgpQrklPyHAprVIzBLO5AHuVMYBm9aQPNPeZFhg dqAg== X-Received: by 10.66.146.66 with SMTP id ta2mr4524485pab.11.1374007925219; Tue, 16 Jul 2013 13:52:05 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id qu10sm3717265pbb.12.2013.07.16.13.52.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 13:52:04 -0700 (PDT) Message-ID: <51E5B270.8010500@gmail.com> Date: Tue, 16 Jul 2013 15:52:00 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "tsv-area@ietf.org" Subject: Feedback request: The desired expertise of a Transport Area Director (updated) References: <51DF09B8.2050506@neclab.eu> <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:52:16 -0000 Thanks to everyone who provided feedback on our proposed job description. After reading through the excellent suggestions, your ADs did a more extensive editing session, resulting in what you see below. Our goal was to make Nomcom's job (and, of course, the IAB-as-confirming-body's job) possible, and we tried to distinguish more clearly between - stuff ADs have to know, and - stuff ADs have to be able to find someone who knows, and understand what they're saying about it We need to provide our description to the just-seated Nomcom (if you'll be serving on this Nomcom, congratulations, and best wishes) by something like the morning (CDT) of Thursday, July 18. We're open to comments until we hand the description over, but if you're reading this after we've sent it to Nomcom, please let Nomcom know about your feedback on the job description itself. (You don't have to convince us, you just have to convince Nomcom :-) Again, thank you, and if your travel plans include IETF 87, we'll see you in Berlin. Spencer and Martin 2013 Transport Expertise The Transport Area works on mechanisms related to end-to-end data transport as well as technologies for network storage, content distribution networks, and peer-to-peer applications. Many transport protocols support Internet applications and services that exchange potentially large volumes of traffic at potentially high bandwidths. A Transport AD should have a broad understanding of core end-to-end transport topics such as congestion control, congestion signaling and congestion management, control loops and hysterisis, flow control, and middleboxes such as NATs and firewalls. Transport ADs are not expected to be experts on all or even most of these topics, but rather to work well with the Transport Area participants who are, and to have enough familiarity with the principles involved to exercise their own good judgment about what should be done and why. A Transport AD should have good relationships with the topic experts in the Transport area, including members of the Transport Area Directorate and RSVP Directorate, and with topic experts in other areas, and this requires good soft skills, including the ability to maintain these directorates. Together, the two Transport ADs are expected to understand how transport technologies (layer 4) interact with IP layer technologies and protocols (layer 3) technologies, and with the end-to-end aspects of various applications and application-layer protocols (layer 7). Together, the two Transport ADs are expected to effectively charter, manage and review current and new transport work, indcluding congestion signaling and reporting, QoS and reservation signaling, DiffServ/Intserv and congestion control for unresponsive flows, NAT regularization and specification, storage protocols for the Internet, peer-to-peer streaming, performance metrics for Internet paths, experimentation with congestion control schemes developed in the IRTF, unicast and multipath extensions to existing transport protocols, and congestion control algorithms for interactive real time media. The Transport Area intersects most frequently with Internet Area, the Applications Area, the RAI Area, the Security Area, and Transport-related IRTF research groups, especially ICCRG. Cross-area experience in any of those Areas would be particularly useful. Because many Transport working groups have strong ties to the research community, some research background can be very helpful. From touch@isi.edu Tue Jul 16 15:41:07 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C567E21F92E7 for ; Tue, 16 Jul 2013 15:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.742 X-Spam-Level: X-Spam-Status: No, score=-105.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoQtzMxbR5Fe for ; Tue, 16 Jul 2013 15:41:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBCA21F896D for ; Tue, 16 Jul 2013 15:41:01 -0700 (PDT) Received: from [128.9.184.195] ([128.9.184.195]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r6GMdtUK012620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jul 2013 15:39:55 -0700 (PDT) Message-ID: <51E5CBC0.7080903@isi.edu> Date: Tue, 16 Jul 2013 15:40:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: Feedback request: The desired expertise of a Transport Area Director (updated) References: <51DF09B8.2050506@neclab.eu> <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> <51E5B270.8010500@gmail.com> In-Reply-To: <51E5B270.8010500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 22:41:07 -0000 Hi, Spencer, On 7/16/2013 1:52 PM, Spencer Dawkins wrote: > A Transport AD should have a broad understanding of core end-to-end > transport topics such as congestion control, congestion signaling and > congestion management, control loops and hysterisis, flow control, and > middleboxes such as NATs and firewalls. As I said, this is insufficient. IMO, it focuses far too much on the congestion issue and not enough on reliability, connection issues, network layer interactions, and application layer interactions. I would suggest rewording it to avoid repeated reference to congestion, and include these other issues: A Transport AD should have a broad understanding of core end-to-end transport topics such as congestion, control loops and hysteresis, flow control, reliability issues, connection issues, and interactions with the network layer, the application layer, and middleboxes. From gettysjim@gmail.com Tue Jul 16 17:38:35 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38221F8F67 for ; Tue, 16 Jul 2013 17:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wZC4wCQzzQs for ; Tue, 16 Jul 2013 17:38:34 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 54BC321F9AA3 for ; Tue, 16 Jul 2013 17:38:34 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so1695974oah.7 for ; Tue, 16 Jul 2013 17:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QAYLRMExMisx3K+Xq5w3sjeNfEmEcwW2u9/p9QSc5r0=; b=hj80lIbt8ROZiTEj7gUg9L8V70+qhUs4vQ8FLjZh5JGPd7vr8J6nlkLHl7C5OGcsjo fzzCe2xj5a62kWTD9Oa7AsY0c+NXaJLJeVQcDARR20dOw63LHNhRjDRzY7n4a466thea tz9Gvfpf6hsL5gzyWOhF8NMq0Q2F0Ljl2HxRlx+FYt3uVetKq1sPaF7iu3iDrnKRyrVx d1rmENqQSer+IDIWq2SaYTAjWjbtSr4OakQzZKd0f9rGJW7EOdHtH1nEo1+dHOoi1s6h mzk98E4yAXKaDYMfjOVuwI5BDA6gfbguV2QqlNA0VW3R1ss5zhGmxnw50n446AE2nA5F khbA== MIME-Version: 1.0 X-Received: by 10.60.103.211 with SMTP id fy19mr5054670oeb.103.1374021513794; Tue, 16 Jul 2013 17:38:33 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.144.67 with HTTP; Tue, 16 Jul 2013 17:38:33 -0700 (PDT) In-Reply-To: <51E5CBC0.7080903@isi.edu> References: <51DF09B8.2050506@neclab.eu> <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> <51E5B270.8010500@gmail.com> <51E5CBC0.7080903@isi.edu> Date: Tue, 16 Jul 2013 20:38:33 -0400 X-Google-Sender-Auth: oLFPBJQgKInlOA9XWGXcKYGHPpU Message-ID: Subject: Re: Feedback request: The desired expertise of a Transport Area Director (updated) From: Jim Gettys To: Joe Touch Content-Type: multipart/alternative; boundary=089e0115e85e3e5b6b04e1aa502b Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:38:35 -0000 --089e0115e85e3e5b6b04e1aa502b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch wrote: > Hi, Spencer, > > > On 7/16/2013 1:52 PM, Spencer Dawkins wrote: > >> A Transport AD should have a broad understanding of core end-to-end >> transport topics such as congestion control, congestion signaling and >> congestion management, control loops and hysterisis, flow control, and >> middleboxes such as NATs and firewalls. >> > > As I said, this is insufficient. IMO, it focuses far too much on the > congestion issue and not enough on reliability, connection issues, network > layer interactions, and application layer interactions. > Yes. I must agree with Joe again, having written in my blog about the misconceptions that many networking engineers and researchers have about applications last week. > > I would suggest rewording it to avoid repeated reference to congestion, > and include these other issues: > > > A Transport AD should have a broad understanding of core end-to-end > transport topics such as congestion, control loops and hysteresis, flow > control, reliability issues, connection issues, and interactions with the > network layer, the application layer, and middleboxes. > There are two words missing entirely that are key: Queuing and, even more important, Latency - Jim --089e0115e85e3e5b6b04e1aa502b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue= , Jul 16, 2013 at 6:40 PM, Joe Touch <touch@isi.edu> wrote:
Hi, Spencer,


On 7/16/2013 1:52 PM, Spencer Dawkins wrote:
A Transport AD should have a broad understanding of core end-to-end
transport topics such as congestion control, congestion signaling and
congestion management, control loops and hysterisis, flow control, and
middleboxes such as NATs and firewalls.

As I said, this is insufficient. IMO, it focuses far too much on the conges= tion issue and not enough on reliability, connection issues, network layer = interactions, and application layer interactions.

Yes. =A0I = must agree with Joe again, having written in my blog about the misconceptio= ns that many networking engineers and researchers have about applications l= ast week.


I would suggest rewording it to avoid repeated reference to congestion, and= include these other issues:


A Transport AD should have a broad understanding of core end-to-end
transport topics such as congestion, control loops and hysteresis, flow con= trol, reliability issues, connection issues, and interactions with the netw= ork layer, the application layer, and middleboxes.

There are = two words missing entirely that are key:

Queuing and, even more important, Latency

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 - Jim


=

--089e0115e85e3e5b6b04e1aa502b-- From spencerdawkins.ietf@gmail.com Tue Jul 16 19:13:30 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9374E21F9B97 for ; Tue, 16 Jul 2013 19:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYQIYIlDrE7Z for ; Tue, 16 Jul 2013 19:13:29 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 51A8021F9B5B for ; Tue, 16 Jul 2013 19:13:14 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so1630336obc.10 for ; Tue, 16 Jul 2013 19:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=3xePBAyX6tKS4KDGUHI+CWAlzhnhp5DcXJloAfwPAtY=; b=dsCJa+nyN18hcQqGu4k9hh/b7/2WbmMQDB5CvgHtiP0qx7TPpVT7HGjZjS85RsmetA M0kKewDtykliu2SYkwJ7CTc4GQWa0sVlC21bdJb/5c2AcqNR4QckVp44ebWW7YLRo1cP sfaK+POaf8w33TE+vhds3icZVLAY+8PPX9lDRQ2iiLdppERqV9o2HNrCh8EKvKVyhEi6 jrGnboNwF4NRuaQbPCCjEEz+P5IsiiOhWu6oioa/2NaikpESKBFWW7+LCOj9zfNMXNns WXIh0a4ap4LB44tfB3d+1aQotV51ujrUsg3f95l+hUYpeSOXOn0rkRkTVudw8yx5rfzr 24EA== X-Received: by 10.60.45.38 with SMTP id j6mr5608812oem.56.1374027192865; Tue, 16 Jul 2013 19:13:12 -0700 (PDT) Received: from [192.168.1.77] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id hm1sm4372977obb.9.2013.07.16.19.13.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 19:13:11 -0700 (PDT) Message-ID: <51E5FDAD.5070203@gmail.com> Date: Tue, 16 Jul 2013 21:13:01 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jim Gettys Subject: Re: Feedback request: The desired expertise of a Transport Area Director (updated) References: <51DF09B8.2050506@neclab.eu> <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> <51E5B270.8010500@gmail.com> <51E5CBC0.7080903@isi.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040504020406000606000207" Cc: Martin Stiemerling , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 02:13:30 -0000 This is a multi-part message in MIME format. --------------040504020406000606000207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/16/2013 7:38 PM, Jim Gettys wrote: > > > > On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch > wrote: > > I would suggest rewording it to avoid repeated reference to > congestion, and include these other issues: > > > A Transport AD should have a broad understanding of core end-to-end > transport topics such as congestion, control loops and hysteresis, > flow control, reliability issues, connection issues, and > interactions with the network layer, the application layer, and > middleboxes. > > > There are two words missing entirely that are key: > > Queuing and, even more important, Latency Thank you both, Joe and Jim, for quick and actionable suggestions! Spencer --------------040504020406000606000207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/16/2013 7:38 PM, Jim Gettys wrote:



On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch <touch@isi.edu> wrote:
I would suggest rewording it to avoid repeated reference to congestion, and include these other issues:


A Transport AD should have a broad understanding of core end-to-end
transport topics such as congestion, control loops and hysteresis, flow control, reliability issues, connection issues, and interactions with the network layer, the application layer, and middleboxes.

There are two words missing entirely that are key:

Queuing and, even more important, Latency

Thank you both, Joe and Jim, for quick and actionable suggestions!

Spencer
--------------040504020406000606000207-- From repenno@cisco.com Tue Jul 16 21:57:05 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FE121F9A26 for ; Tue, 16 Jul 2013 21:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtKKkFzaRXxi for ; Tue, 16 Jul 2013 21:56:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E602221F9A94 for ; Tue, 16 Jul 2013 21:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5097; q=dns/txt; s=iport; t=1374037019; x=1375246619; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tjs9Pjl6kj3D7RdIMbCm8deQHH80pum2rMMFlrTCTZE=; b=ceF+qGcWNc8mKZr6KYFWTxn6BPisOybNtu59BnuCfXY4osI6b9QSh4bO vo3oUbv47FrH5q9O4JDRmvfANM1WyX+WOq0nTwvTFDWtS2CHORAgSgFj8 trlIq80Kb10WSHd6Or95FTmUuLoar0kP3zYOUo3SL8VraeqpXfro2T1ZT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAPYh5lGtJXHB/2dsb2JhbABagkJEgQPCM4EOFnSCIwEBAQQOVwYOEAIBCAQNBAEBCx0HIREUCQgCBAENBQiHdgMPrHMNiF6NBII5MQYBgwxuA4hvjQSOEIUmgVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208,217";a="235736062" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2013 04:56:57 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6H4uup7017484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 04:56:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 23:56:56 -0500 From: "Reinaldo Penno (repenno)" To: Spencer Dawkins , Jim Gettys Subject: RE: Feedback request: The desired expertise of a Transport Area Director (updated) Thread-Topic: Feedback request: The desired expertise of a Transport Area Director (updated) Thread-Index: AQHOgnWVWScZD3HpQ0C2anreDBvkoZloWtSAgAAaZYD//9ShfA== Date: Wed, 17 Jul 2013 04:56:55 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090C7C93@xmb-rcd-x04.cisco.com> References: <51DF09B8.2050506@neclab.eu> <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> <51E5B270.8010500@gmail.com> <51E5CBC0.7080903@isi.edu> , <51E5FDAD.5070203@gmail.com> In-Reply-To: <51E5FDAD.5070203@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.96] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C93xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 04:57:05 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C93xmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I understand technical skills are very important, but they comprise most of= the list. There is mention of "and this requires good soft skills" but I w= onder if we can say something more concrete? How about "management experience" ? Without detracting from the technical r= equirements, in my opinion given an AD role soft skills are as important. A= Ds should have "strong soft skills". This is a good opportunity to balance= things a bit more. thanks, Reinaldo ________________________________ From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] on behalf of Sp= encer Dawkins [spencerdawkins.ietf@gmail.com] Sent: Tuesday, July 16, 2013 7:13 PM To: Jim Gettys Cc: Martin Stiemerling; tsv-area@ietf.org Subject: Re: Feedback request: The desired expertise of a Transport Area Di= rector (updated) On 7/16/2013 7:38 PM, Jim Gettys wrote: On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch > wrote: I would suggest rewording it to avoid repeated reference to congestion, and= include these other issues: A Transport AD should have a broad understanding of core end-to-end transport topics such as congestion, control loops and hysteresis, flow con= trol, reliability issues, connection issues, and interactions with the netw= ork layer, the application layer, and middleboxes. There are two words missing entirely that are key: Queuing and, even more important, Latency Thank you both, Joe and Jim, for quick and actionable suggestions! Spencer --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C93xmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I understand technical skills are very important, but they comprise = most of the list. There is mention of "and this requ= ires good soft skills" but I wonder if we can say something more concrete? 

How about "management experience" ? Without detracting from = the technical requirements, in my opinion given an AD role soft skills are = as important. ADs should have "strong soft skills".  This is= a good opportunity to balance things a bit more.

thanks,

Reinaldo

From: tsv-area-bounces@ietf.org [tsv-are= a-bounces@ietf.org] on behalf of Spencer Dawkins [spencerdawkins.ietf@gmail= .com]
Sent: Tuesday, July 16, 2013 7:13 PM
To: Jim Gettys
Cc: Martin Stiemerling; tsv-area@ietf.org
Subject: Re: Feedback request: The desired expertise of a Transport = Area Director (updated)

On 7/16/2013 7:38 PM, Jim Gettys wrote:



On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch <touch@isi.edu>= ; wrote:
I would suggest rewording it to avoid repeated reference to congestion, and= include these other issues:


A Transport AD should have a broad understanding of core end-to-end
transport topics such as congestion, control loops and hysteresis, flow con= trol, reliability issues, connection issues, and interactions with the netw= ork layer, the application layer, and middleboxes.

There are two words = missing entirely that are key:

Queuing and, even mo= re important, Latency

Thank you both, Joe and Jim, for quick and actionable suggestions!

Spencer
--_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C93xmbrcdx04ciscoc_-- From spencerdawkins.ietf@gmail.com Wed Jul 17 05:52:45 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5F721F86BE for ; Wed, 17 Jul 2013 05:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUf-xOEgDbLf for ; Wed, 17 Jul 2013 05:52:42 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 958E421F873C for ; Wed, 17 Jul 2013 05:52:40 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m1so2435354oag.20 for ; Wed, 17 Jul 2013 05:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=wkhAP1HLR1A7eu1Z2oxAjfAX3BFLqeNQPzYI8c4F+sU=; b=n6zh8l2Ms90STMv9ukqOjs+k9tKU8gw92Ko6RPMpVD+Z6kPpLCOOtTf4v71mtYc1BR Xp9jzjkYhjz7uCWITY/EChUuqE/gUYWiUpIlfjjyrYPIAeUOf/Kwt56VQxnOxYX2iPVC MndFQNZWm/4x5PDRE/dMyQyfSBczMhDC23fiCvYWB8z4wAMmdE9Qn6U7CpYCme1zqcfs vxgejnyYQSL+Dm+1i34rPZxmimyv5GAkPOYt8rNYF/cWFWXDKocjVW1Qm+G+aabWZnmw Bz6tL+Fxhif+InAlkoZkkf3yu+jlpSEKZxtxiFKpDc3lhO2o2Bt3REeIMO4xOQFMPubc NAgw== X-Received: by 10.60.131.171 with SMTP id on11mr7948755oeb.71.1374065560139; Wed, 17 Jul 2013 05:52:40 -0700 (PDT) Received: from [192.168.1.77] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id d4sm7189304oby.1.2013.07.17.05.52.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 05:52:38 -0700 (PDT) Message-ID: <51E69388.8040402@gmail.com> Date: Wed, 17 Jul 2013 07:52:24 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" Subject: Re: Feedback request: The desired expertise of a Transport Area Director (updated) References: <51DF09B8.2050506@neclab.eu> <8D3D17ACE214DC429325B2B98F3AE712983F364E@MX15A.corp.emc.com> <51E5B270.8010500@gmail.com> <51E5CBC0.7080903@isi.edu> , <51E5FDAD.5070203@gmail.com> <45A697A8FFD7CF48BCF2BE7E106F0604090C7C93@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090C7C93@xmb-rcd-x04.cisco.com> Content-Type: multipart/alternative; boundary="------------040602040108000302010907" Cc: Martin Stiemerling , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:52:45 -0000 This is a multi-part message in MIME format. --------------040602040108000302010907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/16/2013 11:56 PM, Reinaldo Penno (repenno) wrote: > I understand technical skills are very important, but they comprise > most of the list. There is mention of "and this requires good soft > skills" but I wonder if we can say something more concrete? > > How about "management experience" ? Without detracting from the > technical requirements, in my opinion given an AD role soft skills are > as important. ADs should have "strong soft skills". This is a good > opportunity to balance things a bit more. Hi, Reinaldo, Although Martin included this pointer to a "Generic Expertise" write-up in his earlier e-mail asking for feedback, I didn't include it in the e-mail you replied to (sorry!) http://trac.tools.ietf.org/group/iesg/trac/wiki/GenericExpertise We're thinking that the "Generic Expertise" section captures much of what we needed to say about the needed "soft skills" for TSV ADs, but your note reminded us that the TSVAREA Nomcom discussion at IETF 86 ALSO skipped over the "Generic Expertise" material, so we're adding a back-reference to "Generic Expertise" in the TSV description. So, thank you for sending your note - it had an effect. Spencer and Martin > thanks, > > Reinaldo > > ------------------------------------------------------------------------ > *From:* tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] on > behalf of Spencer Dawkins [spencerdawkins.ietf@gmail.com] > *Sent:* Tuesday, July 16, 2013 7:13 PM > *To:* Jim Gettys > *Cc:* Martin Stiemerling; tsv-area@ietf.org > *Subject:* Re: Feedback request: The desired expertise of a Transport > Area Director (updated) > > On 7/16/2013 7:38 PM, Jim Gettys wrote: >> >> >> >> On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch > > wrote: >> >> I would suggest rewording it to avoid repeated reference to >> congestion, and include these other issues: >> >> >> A Transport AD should have a broad understanding of core end-to-end >> transport topics such as congestion, control loops and >> hysteresis, flow control, reliability issues, connection issues, >> and interactions with the network layer, the application layer, >> and middleboxes. >> >> >> There are two words missing entirely that are key: >> >> Queuing and, even more important, Latency > > Thank you both, Joe and Jim, for quick and actionable suggestions! > > Spencer --------------040602040108000302010907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/16/2013 11:56 PM, Reinaldo Penno (repenno) wrote:
I understand technical skills are very important, but they comprise most of the list. There is mention of "and this requires good soft skills" but I wonder if we can say something more concrete? 

How about "management experience" ? Without detracting from the technical requirements, in my opinion given an AD role soft skills are as important. ADs should have "strong soft skills".  This is a good opportunity to balance things a bit more.

Hi, Reinaldo,

Although Martin included this pointer to a "Generic Expertise" write-up in his earlier e-mail asking for feedback, I didn't include it in the e-mail you replied to (sorry!)

http://trac.tools.ietf.org/group/iesg/trac/wiki/GenericExpertise

We're thinking that the "Generic Expertise" section captures much of what we needed to say about the needed "soft skills" for TSV ADs, but your note reminded us that the TSVAREA Nomcom discussion at IETF 86 ALSO skipped over the "Generic Expertise" material, so we're adding a back-reference to "Generic Expertise" in the TSV description.

So, thank you for sending your note - it had an effect.

Spencer and Martin

thanks,

Reinaldo

From: tsv-area-bounces@ietf.org [tsv-area-bounces@ietf.org] on behalf of Spencer Dawkins [spencerdawkins.ietf@gmail.com]
Sent: Tuesday, July 16, 2013 7:13 PM
To: Jim Gettys
Cc: Martin Stiemerling; tsv-area@ietf.org
Subject: Re: Feedback request: The desired expertise of a Transport Area Director (updated)

On 7/16/2013 7:38 PM, Jim Gettys wrote:



On Tue, Jul 16, 2013 at 6:40 PM, Joe Touch <touch@isi.edu> wrote:
I would suggest rewording it to avoid repeated reference to congestion, and include these other issues:


A Transport AD should have a broad understanding of core end-to-end
transport topics such as congestion, control loops and hysteresis, flow control, reliability issues, connection issues, and interactions with the network layer, the application layer, and middleboxes.

There are two words missing entirely that are key:

Queuing and, even more important, Latency

Thank you both, Joe and Jim, for quick and actionable suggestions!

Spencer

--------------040602040108000302010907-- From Martin.Stiemerling@neclab.eu Fri Jul 19 02:47:53 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C2021E8095 for ; Fri, 19 Jul 2013 02:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH+7bOUwtAHK for ; Fri, 19 Jul 2013 02:47:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E659C21E808D for ; Fri, 19 Jul 2013 02:47:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2134A104BF8 for ; Fri, 19 Jul 2013 11:47:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sGyyJqddv80 for ; Fri, 19 Jul 2013 11:47:09 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 0503D104BE2 for ; Fri, 19 Jul 2013 11:47:04 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 19 Jul 2013 11:47:21 +0200 Message-ID: <51E90A2E.6010703@neclab.eu> Date: Fri, 19 Jul 2013 11:43:10 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Subject: Meet your ADs in Berlin / TSV AD "office hours" @IETF87 in Berlin Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:47:53 -0000 Hi there, This is an early announcement of the TSV AD "office hours" at the IETF-87 meeting in Berlin. The office hours are for the case there are things that you need to discuss with us in person and aren't able to pin us down any other time. However, you can also drop by if you just want to say hello. The current time slot reserved for the office hours is **11:30 - 13:00 Thursday, August 1st, lunch break We do not yet know the room number of the IESG room. The room will be announced soon. Thanks, Martin From wes@mti-systems.com Sun Jul 21 06:49:46 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DAC21E808A for ; Sun, 21 Jul 2013 06:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAjZar6B6GiH for ; Sun, 21 Jul 2013 06:49:41 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E68521E8088 for ; Sun, 21 Jul 2013 06:49:36 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r6LDnZvK001900 for ; Sun, 21 Jul 2013 09:49:35 -0400 Received: (qmail 1579 invoked by uid 0); 21 Jul 2013 13:49:35 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.122?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 21 Jul 2013 13:49:35 -0000 Message-ID: <51EBE6E6.6010601@mti-systems.com> Date: Sun, 21 Jul 2013 09:49:26 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: tsv-area@ietf.org Subject: AQM BoF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 13:49:46 -0000 Following up after the last TSVAREA meeting where this was discussed: We are trying to start a working group in the IETF to focus on Active Queue Management (AQM) and packet scheduling or fair queuing algorithms. There is a mailing list setup at: https://www.ietf.org/mailman/listinfo/aqm Anyone interested is free and welcomed to join the discussion. We especially want to have people with different perspectives participating, including hardware and software developers for different types of systems, network operators, academics, etc. There will also be a Birds of a Feather (BoF) meeting at the IETF meeting in Berlin (http://www.ietf.org/meeting/87) later this month, which we wanted to make people aware of. The goal of the meeting is to form a working group following the meeting. A draft charter that is being discussed can be found here: http://www.ietf.org/mail-archive/web/aqm/current/msg00165.html -- Wes Eddy MTI Systems From Martin.Stiemerling@neclab.eu Sun Jul 28 01:33:33 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBD921F99C7 for ; Sun, 28 Jul 2013 01:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.258 X-Spam-Level: X-Spam-Status: No, score=-103.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0h12JURtri7 for ; Sun, 28 Jul 2013 01:33:28 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78521F941F for ; Sun, 28 Jul 2013 01:33:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E4A8C104D15 for ; Sun, 28 Jul 2013 10:32:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8XEI3C4DuYV for ; Sun, 28 Jul 2013 10:32:44 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C7DF7104C82 for ; Sun, 28 Jul 2013 10:32:39 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 28 Jul 2013 10:33:22 +0200 Message-ID: <51F4D752.4040506@neclab.eu> Date: Sun, 28 Jul 2013 10:33:22 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Subject: Re: Meet your ADs in Berlin / TSV AD "office hours" @IETF87 in Berlin References: <51E90A2E.6010703@neclab.eu> In-Reply-To: <51E90A2E.6010703@neclab.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 08:33:33 -0000 Hi all, To complete the information about the TSV "office hours" here in Berlin: Location: Chess Time: 11:30 to 13:00 Martin On 07/19/2013 11:43 AM, Martin Stiemerling wrote: > Hi there, > > This is an early announcement of the TSV AD "office hours" at the > IETF-87 meeting in Berlin. > > The office hours are for the case there are things that you need to > discuss with us in person and aren't able to pin us down any other time. > > However, you can also drop by if you just want to say hello. > > > The current time slot reserved for the office hours is > **11:30 - 13:00 Thursday, August 1st, lunch break > > We do not yet know the room number of the IESG room. The room will be > announced soon. > > Thanks, > > Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From lars@netapp.com Sun Jul 28 04:16:05 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9982021F9C50; Sun, 28 Jul 2013 04:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.159 X-Spam-Level: X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[AWL=-2.560, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a54XLEwrXHdm; Sun, 28 Jul 2013 04:16:00 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1A41321F9DA9; Sun, 28 Jul 2013 04:15:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,763,1367996400"; d="scan'208";a="37174233" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 28 Jul 2013 04:15:56 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Sun, 28 Jul 2013 04:15:56 -0700 From: "Eggert, Lars" To: "" , "rai@ietf.org" , "iccrg@irtf.org" Subject: ANRP winner talk on rate control for media streaming in IRTFOPEN Thread-Topic: ANRP winner talk on rate control for media streaming in IRTFOPEN Thread-Index: AQHOi4PTHptGeaB2rkuiggtXSig/3A== Date: Sun, 28 Jul 2013 11:15:55 +0000 Message-ID: <68D007A2-9596-4D64-8426-7B99410BEF25@netapp.com> References: <76B78224-2A21-48F2-94ED-FE5CFD32A2BC@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="utf-8" Content-ID: <602583D611B0614B8ED1C3E111D24902@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 11:16:05 -0000 SGksDQoNCnRoZSBmb2xsb3dpbmcgdGFsayBieSBBTlJQIDIwMTMgcHJpemUgd2lubmVyIExhdXJl bnQgVmFuYmV2ZXIgaXMgcHJvYmFibHkgb2YgaW50ZXJlc3QgdG8gc29tZSBSQUkgYW5kIFRTViBm b2xrcy4gVGhlIHRhbGsgd2lsbCBzdGFydCBhdCBhcHByb3guIDk6MTVBTSBvbiBUdWVzZGF5Og0K DQo+ICAgICAqKiogVEUtWVVBTiBIVUFORyAqKiogZm9yIGluc2lnaHRzIGludG8gdGhlIGRpZmZp Y3VsdGllcyBvZiByYXRlDQo+ICAgICBhZGFwdGF0aW9uIGZvciBzdHJlYW1pbmcgdmlkZW86DQo+ ICAgICANCj4gICAgICAgICBUZS1ZdWFuIEh1YW5nLCBOaWtoaWwgSGFuZGlnb2wsIEJyYW5kb24g SGVsbGVyLCBOaWNrIE1jS2Vvd24NCj4gICAgICAgICBhbmQgUmFtZXNoIEpvaGFyaS4gQ29uZnVz ZWQsIFRpbWlkLCBhbmQgVW5zdGFibGU6IFBpY2tpbmcgYQ0KPiAgICAgICAgIFZpZGVvIFN0cmVh bWluZyBSYXRlIGlzIEhhcmQuIFByb2MuIEFDTSBJbnRlcm5ldCBNZWFzdXJlbWVudA0KPiAgICAg ICAgIENvbmZlcmVuY2UgKElNQyksTm92ZW1iZXIgMjAxMiwgQm9zdG9uLCBNQSwgVVNBLg0KPiAg ICAgDQo+ICAgICAgICAgVG9kYXnigJlzIGNvbW1lcmNpYWwgdmlkZW8gc3RyZWFtaW5nIHNlcnZp Y2VzIHVzZSBkeW5hbWljIHJhdGUNCj4gICAgICAgICBzZWxlY3Rpb24gdG8gcHJvdmlkZSBhIGhp Z2gtcXVhbGl0eSB1c2VyIGV4cGVyaWVuY2UuIFdlDQo+ICAgICAgICAgbWVhc3VyZSB0aHJlZSBw b3B1bGFyIHZpZGVvIHN0cmVhbWluZyBzZXJ2aWNlcyBhbmQg76yBbmQgdGhhdA0KPiAgICAgICAg IGFjY3VyYXRlIGNsaWVudC1zaWRlIGJhbmR3aWR0aCBlc3RpbWF0aW9uIGFib3ZlIHRoZSBIVFRQ DQo+ICAgICAgICAgbGF5ZXIgaXMgaGFyZC4gQXMgYSByZXN1bHQsIHJhdGUgc2VsZWN0aW9uIGJh c2VkIG9uDQo+ICAgICAgICAgaW5hY2N1cmF0ZSBlc3RpbWF0ZXMgY2FuIHRyaWdnZXIgYSBmZWVk YmFjayBsb29wLCBsZWFkaW5nIHRvDQo+ICAgICAgICAgdW5kZXNpcmFibHkgdmFyaWFibGUgYW5k IGxvdy1xdWFsaXR5IHZpZGVvLiBJbiB0aGlzIHRhbGssIHdlDQo+ICAgICAgICAgd2lsbCBwcmVz ZW50IGluc2lnaHRzIGludG8gaXRzIHJvb3QgY2F1c2VzIGFuZCB2YWxpZGF0ZQ0KPiAgICAgICAg IGluaXRpYWwgc29sdXRpb25zIHRvIHByZXZlbnQgaXQuDQoNCkxhcnM= From Martin.Stiemerling@neclab.eu Tue Jul 30 01:02:03 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A21321E80D4 for ; Tue, 30 Jul 2013 01:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b5oVYiiGSAz for ; Tue, 30 Jul 2013 01:01:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C197021E80CC for ; Tue, 30 Jul 2013 01:01:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 08C20103A52 for ; Tue, 30 Jul 2013 10:01:14 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XjQy5VY6iq8 for ; Tue, 30 Jul 2013 10:01:13 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E3583103A4B for ; Tue, 30 Jul 2013 10:01:08 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 30 Jul 2013 10:01:32 +0200 Message-ID: <51F772DB.1070105@neclab.eu> Date: Tue, 30 Jul 2013 10:01:31 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Subject: Looking for a new co-chair for PPSP Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:02:03 -0000 Dear all, Stefano Previdi will step down as co-chair of the PPSP WG [1]. I am now looking for volunteers to step forward as candidates for the PPSP co-chair position. Please send an email to tsv-ads@tools.ietf.org or directly to me if you are interested in being PPSP co-chair until August 7, 1pm CEST. If you send your email today or this week, we may have a chance to meet also with you. In the case you're wondering what a chair is supposed to do, please email or talk with Spencer or me. Let me thank Stefano for his service as PPSP co-chair! Martin [1] https://datatracker.ietf.org/wg/ppsp/ -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014