Re: [Patient] the IETF participant choice

Tony Rutkowski <> Mon, 19 March 2018 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 125E4127058 for <>; Mon, 19 Mar 2018 13:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yo8zTjeqX7uJ for <>; Mon, 19 Mar 2018 13:38:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7403B12D93F for <>; Mon, 19 Mar 2018 13:38:16 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1113A540177; Mon, 19 Mar 2018 20:38:13 +0000 (GMT)
To: Ted Lemon <>
Cc: "" <>, Brian Witten <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tony Rutkowski <>
Organization: Yaana Limited
Message-ID: <>
Date: Mon, 19 Mar 2018 16:38:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------85B527A91B57CD360E05A7AC"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Patient] the IETF participant choice
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Mar 2018 20:38:19 -0000

The concern here begs the question, "whose" systems analysis? The IETF 
is not some kind of Land of Oz where a wizard has the answers to all 
manner of complex systems requirements.  There are many competing 
requirements across all manner of data centres, architectures, 
providers, and user communities.  Meaningful implementations will also 
require acceptance and adoption by an equally broad array of communities.

There are no solution singularities here, and multiple tailored 
specifications are certain to emerge.  The academic and patent 
literature evidences several dozen of them. Indeed, whatever any 
standards body does will be competing with a large number of proprietary 
solutions.  The only certainty is the demand for effective solutions.

In TC CYBER, we are moving ahead with our own and evolving them in light 
of this reality - hopefully with essential reflection and criticism from 
IETF participants.


On 19-Mar-18 4:07 PM, Ted Lemon wrote:
> On Mar 19, 2018, at 8:01 PM, Tony Rutkowski < 
> <>> wrote:
>> In participating remotely, it was apparent that although the 
>> proponents of the data centre visibility proposal did an excellent 
>> job in articulating the need, the solution was not going to be 
>> undertaken by the IETF.  The result in consonant with countless other 
>> similar initiatives sought in the IETF over the past several decades.
> The thing is, at least from my perspective, we haven't done a systems 
> analysis yet, and so it was just premature to try to get the TLS 
> working group to weaken TLS in order to solve the problem.   For 
> example, the claim was made that it would be "too expensive" to do 
> anything _other_ than modify TLS, but where's the analysis to support 
> that position? Too expensive to use middleboxes, but where's the 
> analysis there?
> This is really an ops problem.   IETF can do ops work, but ops isn't 
> about changing protocols—it's about figuring out good solutions to 
> problems.   Sometimes the answer to an ops problem is "we need some 
> protocol work done," but that's not the starting point.
> As a consequence, I feel like some very well-meaning people came to 
> the IETF with hat in hand and didn't get what they'd hoped for, and 
> probably have the impression that people here don't care about their 
> problem, when that's not actually the case.   Lots of people I talked 
> to who were against the proposed solution care very much about the 
> problem.
> _______________________________________________
> PATIENT mailing list