Re: Split the IANA functions?

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 06 January 2014 22:45 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E7D5B1AE29A for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 14:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 A0OtXwrf5ZxM for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 14:45:19 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 585CF1AE2A7 for <ietf@ietf.org>; Mon, 6 Jan 2014 14:45:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C4B5BE33; Mon, 6 Jan 2014 22:45:09 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbgp3p9sd00M; Mon, 6 Jan 2014 22:45:08 +0000 (GMT)
Received: from [10.87.48.14] (unknown [86.45.52.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 50A07BE35; Mon, 6 Jan 2014 22:45:08 +0000 (GMT)
Message-ID: <52CB31F4.3090703@cs.tcd.ie>
Date: Mon, 06 Jan 2014 22:45:08 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: John Curran <jcurran@istaff.org>, Phillip Hallam-Baker <hallam@gmail.com>
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>
In-Reply-To: <DD618936-0D13-41F1-8D89-2E3171D864B5@istaff.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 06 Jan 2014 22:45:21 -0000

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.

S.