Re: Split the IANA functions?

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 07 January 2014 03:16 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 4EEE41AE3E1 for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 19:16:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 c81BKA4w7xZi for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 19:16:06 -0800 (PST)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD51AE3E0 for <ietf@ietf.org>; Mon, 6 Jan 2014 19:16:06 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id kp14so17578439pab.37 for <ietf@ietf.org>; Mon, 06 Jan 2014 19:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2gZDHRGBplbAOiaMdAr71U1qpYh/klg7/Kc22qN5EhI=; b=UtDE9AvxfgN5Dnvt5i/tKX6vdyszSug+FqR2jWe87nQOYyDVRB9QdzSGwJOfiDShaM rrgB+eN2LduS05U79tQvTa2QdvEAJzcOE3FjOv9lrsjm2JzAbTlKabyxRQ2eU3Hu1A0n wyq8qr+/Ic09JpluBtCU6Bx76fwK9oScQ9ZC5RgHusmm6u7SH0QmdUUxRhnkPqMTq/JE pnnsz3oWa3jRZDJSjgYvCRv6eyOYdsbT9CXpORmFXiGeEQzmxRrGMMqlhUaPiNCCVWaV 1+RVhmm8HwXo5V52ZDshBaVq399iyetxrExbafWO28TtwBe3jXkRoMlorXt+Ixv9GGgL HHCg==
X-Received: by 10.66.160.195 with SMTP id xm3mr2153463pab.93.1389064557575; Mon, 06 Jan 2014 19:15:57 -0800 (PST)
Received: from [192.168.178.21] (122.195.69.111.dynamic.snap.net.nz. [111.69.195.122]) by mx.google.com with ESMTPSA id ik1sm132191960pbc.9.2014.01.06.19.15.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 19:15:56 -0800 (PST)
Message-ID: <52CB716E.6090205@gmail.com>
Date: Tue, 07 Jan 2014 16:15:58 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: John Curran <jcurran@istaff.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> <0B57AB63-CA73-42BD-94C3-E20983FF4432@istaff.org>
In-Reply-To: <0B57AB63-CA73-42BD-94C3-E20983FF4432@istaff.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 07 Jan 2014 03:16:08 -0000

On 07/01/2014 14:27, John Curran wrote:
> On Jan 6, 2014, at 5:45 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> On 01/06/2014 08:51 PM, John Curran wrote:
>>> What happens when the IETF makes a decision that particular "public policy" requirements 
>>> are _to be considered_ (perpass), or specifically _not to be considered_ (RFC 2804) in protocol
>>> development? 
>> I think that's a mis-characterisation. IMO both of those are cases
>> where there are sound technical reasons for the IETF to do, or not
>> do, work. Yes, those have impacts, but the public policy angle (if
>> that's the right term) is a side-effect and is not the reason for
>> the decision.
> 
> Stephen - 
>  
>  I did not mean to imply that the primary driver was the IETF taking
>  on a public policy matter; only that the decision being made (even 
>  if on a sound technical basis) have real public policy implications, 
>  and thus will attract interest of many non-technical parties, including
>  governments.

Of course, this has been true of every major technology innovation for
the last couple of thousand years, once the technology pervades society.
So we shouldn't be surprised or alarmed when public policy implications
of IETF technical decisions show up.

It's certainly true that in the current case, and the cases of RFC 1984
and 2804, there were public events and debates prior to the IETF taking
a position. I don't see why we should be worried by that either, as long
as we take technically based decisions that help the Internet work better.

    Brian