[Patient] the IETF participant choice

Tony Rutkowski <tony@yaanatech.co.uk> Mon, 19 March 2018 20:01 UTC

Return-Path: <tony@yaanatech.co.uk>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C446C129C6A for <patient@ietfa.amsl.com>; Mon, 19 Mar 2018 13:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q_EvNgcv49X for <patient@ietfa.amsl.com>; Mon, 19 Mar 2018 13:01:31 -0700 (PDT)
Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E072129C6E for <patient@ietf.org>; Mon, 19 Mar 2018 13:01:30 -0700 (PDT)
Received: from [192.168.1.53] (pool-70-106-194-121.clppva.fios.verizon.net [70.106.194.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id 44634540177; Mon, 19 Mar 2018 20:01:28 +0000 (GMT)
Reply-To: tony@yaanatech.co.uk
To: Brian Witten <brian_witten@symantec.com>, "patient@ietf.org" <patient@ietf.org>
References: <MWHPR16MB14881688FE400E3277CA8A9393310@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889BEE3EB0ED5F328D7C3993370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889B7535153E5844649CA393370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14880A12D15AC58FDD5CEC8793370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488D43F3B53BC7BBE9D836593370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488853B0E4F7BB8E557288D93370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB148845FB069D03625BC399B193370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com> <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com> <alpine.LRH.2.21.1712141805020.15188@bofh.nohats.ca> <MWHPR16MB148859D8FC007D9B9D5005E6930A0@MWHPR16MB1488.namprd16.prod.outlook.com> <988132f9-478d-2012-9ad2-353534f07db7@yaanatech.co.uk>
From: Tony Rutkowski <tony@yaanatech.co.uk>
Organization: Yaana Limited
Message-ID: <e89e816d-76da-c062-b3fc-ae2e73c176ae@yaanatech.co.uk>
Date: Mon, 19 Mar 2018 16:01:27 -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: <988132f9-478d-2012-9ad2-353534f07db7@yaanatech.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/9a3Al-4DigYy1Dpiip3aQEjXDDw>
Subject: [Patient] the IETF participant choice
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2018 20:01:33 -0000

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.

In a sense, the outcome today is their right.  Technical collaborative 
bodies are substantially homes to communities who create and maintain 
them to do work they believe necessary.  There are also many other 
collaborative bodies that can undertake the same work, and arguably do a 
better job because the participants are more motivated in getting the 
work done.  It is not apparent what purpose is served in forcing a 
collaborative community - whether it be the IETF or any other standards 
body - to do work they do not want to undertake.

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.

Lastly, the ETSI rapporteurs have reached out to every other 
identifiable "visibility" collaborative and standards activity, 
including the IETF.  Going forward, it is hoped that IETF participants 
will help improve the ETSI standards for capabilities that forever 
reason, cannot be pursued in the IETF.

--tony