Re: Appointment of a Transport Area Director

Toerless Eckert <eckert@cisco.com> Thu, 07 March 2013 06:56 UTC

Return-Path: <eckert@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2AC21F8A99 for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 22:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.134
X-Spam-Level:
X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 OmweDiJpLRiP for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 22:56:53 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E01FD21F8739 for <ietf@ietf.org>; Wed, 6 Mar 2013 22:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1669; q=dns/txt; s=iport; t=1362639414; x=1363849014; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=kpsEPhrPocREtpRatPsrXc3BMq8TkumfFleznT47qs4=; b=l6wky8ruj34kmIIr5AelJRBkfgJL4Sz80UEr4ku7b+n1v3/P4Os9B49C KlpefJyaEd7JNv/2VfYgo6gLTc+yQCXqH6hJOWUo9MGE2gf0/AIMA0VCl 3g5AtJsSsJ7PAQ6O0YCs5Tbb/ggIVK0n7joDivGsYoZtRr4wG+rf4n/ay o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAKc5OFGrRDoI/2dsb2JhbABDxEyBZhZzgisBAQEEMgFGEAsOBAYJJQ8FNRQTiBK7WI1AgUwHg0ADiGyNXgGQcYMq
X-IronPort-AV: E=Sophos;i="4.84,800,1355097600"; d="scan'208";a="74533483"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 Mar 2013 06:56:53 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r276umYX011610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Mar 2013 06:56:48 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r276tr0e032053; Wed, 6 Mar 2013 22:56:08 -0800
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r276tqmf032052; Wed, 6 Mar 2013 22:55:52 -0800
Date: Wed, 06 Mar 2013 22:55:52 -0800
From: Toerless Eckert <eckert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>
Subject: Re: Appointment of a Transport Area Director
Message-ID: <20130307065552.GH20642@cisco.com>
References: <033901ce1996$9c8258e0$4001a8c0@gateway.2wire.net> <290E20B455C66743BE178C5C84F124081A49EEF286@EXMB01CMS.surrey.ac.uk> <003301ce19ab$40e6e9a0$4001a8c0@gateway.2wire.net> <D4D47BCFFE5A004F95D707546AC0D7E91F787238@SACEXCMBX01-PRD.hq.netapp.com> <51363249.1000605@isi.edu> <47029AA2-8072-490A-988A-826577B582B5@tzi.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <47029AA2-8072-490A-988A-826577B582B5@tzi.org>
User-Agent: Mutt/1.4.2.2i
Cc: braden@isi.edu, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2013 06:56:54 -0000

Really ? You don't think a good AD should primarily look for factual evidence
(lab, simulation, interop, ..) results produced by others to judge whether
sufficient work was done to proof that the known entry critera are met 
(like no congestion cllapse) - instead of trying to judge those solely
by himself/herself ? 

On Tue, Mar 05, 2013 at 10:12:43PM +0100, Carsten Bormann wrote:
> On Mar 5, 2013, at 18:58, Bob Braden <braden@isi.edu> wrote:
> 
> > Which is why we learned 30 years ago that building a transport protocol at the application layer is generally a Bad Idea. Why do the same bad ideas keep being reinvented?
> 
> Because we don't have a good selection of transport protocols at the transport layer.
> 
> I'm chairing one of the WGs with a UDP-based application protocol.
> TCP's congestion control, even if we could use TCP, wouldn't do much for us.
> 
> Now here is my point:
> I need TSV ADs that are strong on the technical side.
> A weak TSV AD might be
> -- too cautious, listening to all kinds of Cassandras that haven't bothered to look at the actual protocol, slowing us down unneededly, or
> -- too bold, allowing us to deploy a protocol that causes a congestion collapse that can only be alleviated by physically chiseling nodes out of walls.
> 
> Clearly, I want neither of these to happen.
> (Now, we have received pretty good transport input in 2012, but the IESG will look at this in 2013, and that's where a highly educated decision has to be made.)
> 
> Grüße, Carsten
> 

-- 
---
Toerless Eckert, eckert@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!