Re: Split the IANA functions?

Dave Crocker <dhc@dcrocker.net> Tue, 07 January 2014 06:22 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A726C1AE443 for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 22:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 LXTvqgutakeL for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 22:22:50 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD41AE442 for <ietf@ietf.org>; Mon, 6 Jan 2014 22:22:50 -0800 (PST)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s076Mcdd006601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf@ietf.org>; Mon, 6 Jan 2014 22:22:42 -0800
Message-ID: <52CB9CCF.3070001@dcrocker.net>
Date: Mon, 06 Jan 2014 22:21:03 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Split the IANA functions?
References: <CAMm+LwinAb6+7BoMzwBWyu63vofndxK9VY6DSNN0Ykza4SxuMQ@mail.gmail.com> <52CB0010.5010407@gmail.com> <CAMm+LwhN8+z9q4KQXVY9bWA6TAqxx1=Qg0OUfK=VGCSDg5uWEA@mail.gmail.com> <DD618936-0D13-41F1-8D89-2E3171D864B5@istaff.org> <52CB31F4.3090703@cs.tcd.ie> <52CB987A.20300@cisco.com>
In-Reply-To: <52CB987A.20300@cisco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 06 Jan 2014 22:22:42 -0800 (PST)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Tue, 07 Jan 2014 06:22:52 -0000

On 1/6/2014 10:02 PM, Eliot Lear wrote:
> Why do we state that confidentiality is important to pursue in our
> protocols?  That is a political decision made by the community.  We then
> layer on top of that decision technical requirements.  IMHO it's a very
> important and good political decision.  We struggle with such decisions
> all the time.  That there is a single root is both a technical AND a
> political decision.


Almost any group decision can legitimately be characterized as 
"political".  The decision will favor some and work to the detriment of 
others.  Hence the decision has a component that can be classed as 
exercising "power".

But the reference to politics is distinctly unhelpful for the IETF. 
Whatever the knowledge and experience of our participants individually, 
as a group we lack meaningful, coherent language or practice with it.

What we do have is experience being guided by design criteria stated in 
terms of engineering politics, not social politics.  We tends towards 
greater efficiency, robustness, etc.  This include permitting use of 
various security-related mechanisms for authentication, confidentiality, 
etc.  Political language might cast that as saying that the IETF "favors 
protection of participant data".

But really we are simply taking directives from those who consume our 
work and we are trying to design solutions that satisfy the directives.

There is a community desire to create better participant protections 
from pervasive monitoring.  To be honest, there is also some community 
desire to /permit/ pervasive monitoring.  We choose to listen to our 
"customers" -- that is, those who buy and use what we produce -- rather 
than third-party actors who might favor ensuring that pervasive 
monitoring be made easy.

That choice can be classed as political, but really, we're just 
listening to our market...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net