IETF Logo Mail Archive

RE: Split the IANA functions?

<l.wood@surrey.ac.uk> Mon, 06 January 2014 23:03 UTC

Return-Path: <l.wood@surrey.ac.uk>
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 2634D1AE2BF for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 15:03:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LhHQGDa7bnhh for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 15:03:51 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) by ietfa.amsl.com (Postfix) with ESMTP id D1A441AD8D5 for <ietf@ietf.org>; Mon, 6 Jan 2014 15:03:50 -0800 (PST)
Received: from [85.158.137.99:51157] by server-14.bemta-3.messagelabs.com id 9A/2D-06105-D463BC25; Mon, 06 Jan 2014 23:03:41 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-12.tower-217.messagelabs.com!1389049420!17573288!1
X-Originating-IP: [131.227.200.43]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13520 invoked from network); 6 Jan 2014 23:03:41 -0000
Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-12.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jan 2014 23:03:41 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 6 Jan 2014 23:03:40 +0000
From: l.wood@surrey.ac.uk
To: stephen.farrell@cs.tcd.ie, jcurran@istaff.org, hallam@gmail.com
Date: Mon, 06 Jan 2014 23:03:39 +0000
Subject: RE: Split the IANA functions?
Thread-Topic: Split the IANA functions?
Thread-Index: Ac8LMRDB+gKuNXtjTWSxafMwyM3R5gAAZfu3
Message-ID: <290E20B455C66743BE178C5C84F1240847E63346A8@EXMB01CMS.surrey.ac.uk>
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>
In-Reply-To: <52CB31F4.3090703@cs.tcd.ie>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 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 23:03:54 -0000

Both perpass and RFC2804 are political reactions to the public environment.

To characterize either of them as technically motivated is disingenuous. Neither outlines
a technical approach.

>From RFC2804:
   These questions are believed to be irrelevant to the policy outlined
   in this memo.

See? policy.

>From draft-farrell-perpass-attack-03:

   The technical plenary of the November 2013 IETF meeting
   [IETF88Plenary] discussed pervasive monitoring (or surveillance)
   which requires the monitoring party to take actions that are
   indistinguishable from an attack on Internet communications.
   Participants at that meeting therefore expressed strong agreement
   that this was an attack that should be mitigated where possible via
   the design of protocols that make pervasive monitoring significantly
   more expensive or infeasible.  This Best Current Practice (BCP, see
   [RFC2026] Section 5) formally documents that consensus.

again, policy, pure and simple.

The usual claim that the IETF is a technical organisation that doesn't do politicics
is itself a disingenuous political position...

The public policy angle is the prime motivation for the existence of these
documents. It is not a side-effect.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces@ietf.org] On Behalf Of Stephen Farrell [stephen.farrell@cs.tcd.ie]
Sent: 06 January 2014 22:45
To: John Curran; Phillip Hallam-Baker
Cc: IETF Discussion Mailing List
Subject: Re: Split the IANA functions?

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.

v2.23.0 | Report a Bug | By Email