IETF Logo Mail Archive

Re: Split the IANA functions?

John Curran <jcurran@istaff.org> Tue, 07 January 2014 01:28 UTC

Return-Path: <jcurran@istaff.org>
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 90C901AE3B4 for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 17:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 cUuesRKdEz9b for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 17:28:07 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id B85DF1AE3AB for <ietf@ietf.org>; Mon, 6 Jan 2014 17:28:07 -0800 (PST)
Received: from pool-108-45-30-69.washdc.fios.verizon.net ([108.45.30.69] helo=[192.168.1.9]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1W0LSY-000CYT-3Z; Tue, 07 Jan 2014 01:27:58 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 108.45.30.69
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/ywzFgso6pSAC4J7pb4BwQ
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Split the IANA functions?
From: John Curran <jcurran@istaff.org>
In-Reply-To: <52CB31F4.3090703@cs.tcd.ie>
Date: Mon, 06 Jan 2014 20:27:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B57AB63-CA73-42BD-94C3-E20983FF4432@istaff.org>
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>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1827)
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 01:28:09 -0000

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.

/John

Disclaimer: My views alone.

v2.23.0 | Report a Bug | By Email