Re: [Patient] the IETF participant choice

Tony Rutkowski <> Tue, 20 March 2018 10:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2F931242F7 for <>; Tue, 20 Mar 2018 03:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GgX4zMVySVpO for <>; Tue, 20 Mar 2018 03:44:34 -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 66466124207 for <>; Tue, 20 Mar 2018 03:44:34 -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 C7E2F540231; Tue, 20 Mar 2018 10:44:31 +0000 (GMT)
To: "Eggert, Lars" <>
Cc: "" <>, Brian Witten <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tony Rutkowski <>
Organization: Yaana Limited
Message-ID: <>
Date: Tue, 20 Mar 2018 06:44:30 -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="------------2132C886A26DEA9AEC8277FB"
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: Tue, 20 Mar 2018 10:44:37 -0000

Hi Lars,

Whatever ETSI does will be fully compliant with IPR law.  I am also a 
lawyer and well aware of the IETF's assertions and complaints over the 
years.  The irony here is that TLS is actually an ITU-ISO standard.  
Perhaps we can all just collaborate here on urgently needed 
specifications rather than making threats.


ps. In the early 90s, as ISOC Executive Director, I also helped set up 
the IETF's own rather unique IPR arrangements because of its lack of 
legal existence, and effected the purchase of considerable liability 
insurance for IETF decision makers. Presumably that still exists. :-)

On 20-Mar-18 6:00 AM, Eggert, Lars wrote:
> Hi,
> On 2018-3-19, at 20:01, Tony Rutkowski <> wrote:
>> ETSI TC CYBER spent more than a year studying the "visibility" ecosystem, the requirements, venues, and technologies across a swath of industries worldwide - including what was occurring in academic research and published patents.  It published what is still the most comprehensive technical report on the subject.  And, it has moved ahead with four visibility technical specifications, a workshop, and a hackathon.  (Frankly, controls for levels of "observability" and "granularity" seem like better choices for capabilities being sought.
>> The proposed ETSI TC CYBER technical specifications address both network based and data center based requirements - both in-band and out-of- band - with techniques that are arguably best of breed and drawn from existing R&D.  To the extent there are omissions or failings, the ETSI processes are entirely open and the work will evolve and institute corrections.
> if ETSI TC CYBER is seriously embarking on a path that modifies IETF-originated standards without the IETF's explicit prior agreement, they are setting themselves up for a very visible and politically embarrassing failure.
> We had the same type of conflict with the ITU-T serval times in the past. ETSI TC CYBER might want to check how well that went for the ITU-T.
> Lars
> _______________________________________________
> PATIENT mailing list