Re: [Internetgovtech] Cross community

John Curran <> Thu, 24 July 2014 23:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EDF821A0444 for <>; Thu, 24 Jul 2014 16:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CUAo4f5_3bsy for <>; Thu, 24 Jul 2014 16:23:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B4761A03E1 for <>; Thu, 24 Jul 2014 16:23:24 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <>) id 1XASM7-000DQU-3y; Thu, 24 Jul 2014 23:23:23 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1+q9dLnSZK0eYuLXD75FmEY
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Curran <>
In-Reply-To: <>
Date: Thu, 24 Jul 2014 16:52:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: S Moonesamy <>
X-Mailer: Apple Mail (2.1878.6)
Cc:, Avri Doria <>
Subject: Re: [Internetgovtech] Cross community
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jul 2014 23:23:26 -0000

On Jul 24, 2014, at 1:08 PM, S Moonesamy <> wrote:
> At 07:16 24-07-2014, John Curran wrote:
>> You seem to believe that the IETF does not make "policy" for identifiers,
>> but in fact, IANA registries are specifically required to have policies
>> (see RFC 5226, "Guidelines for Writing an IANA Considerations Section in
>> RFCs") so that the IANA knows what exactly to do in administration.
> My choice of words was incorrect.  You explained it better in the paragraph quoted below.


>> Now it is true that these policies are generally technical in nature and
>> tend to avoid "public policy" positions, but that is not a hard requirement
>> for either IETF protocols or the associated registries.  For example, it
>> is possible for the IETF to define a protocol (e.g. an enhancement to DNS)
>> whereby the protocol itself has some embedded rules for certain identifiers
>> (e.g. the string "curran" shall always return empty set on any query...)
> Ok.

i.e. technical registry policy is part of protocol specification; the IETF
can indeed make a mess of either, but is inclined to try and make it so the 
resulting protocol & registry useful for the Internet.

>> It's worth encouraging the IETF to work on predominantly technical issues,
>> and to delegate the public policy issues that come with general purpose
>> registries to bodies which are supported by the affected community, but
>> at the end of the day, that is nothing more than a polite suggestion to the
>> IETF, and may or may not be followed.  If the IETF were to make a serious
>> misstep, then it runs the risk of parties going elsewhere to work on their
>> protocol standard needs, and that's likely a reasonable deterrent with a
>> natural counterbalance.
> Yes.
> The problem is that it is not always clear at the time the decision was taken whether the misstep is serious.

A single misstep is unlikely to cause folks to go to another venue for
their Internet standards development; it would probably take a pattern of 
decisions which impact others without reasonable opportunity for input to
cause such an outcome.  This is very unlikely given the open nature of 
IETF standards development, but does highlight the need for the various
organizations (IETF, ICANN, RIRs) to keep each other apprised of any policy
or standards development that may be of cross interest.  This has worked 
very well between the RIRs and the IETF, okay with the RIRs and ICANN from 
what I can tell (and I do not know how well the IETF/ICANN communication 
in this area has worked.)

>  In addition, there are a handful of people who would bother to raise any objection if something is considered as a misstep as:
>  (a) The person is not making or losing money because of the decision; or
>  (b) The person will be labelled as querulous.
>  (c) It is bad for the person's career.

And such folks are free to write Internet Drafts which describe the problem 
(as they see it) with a given protocol or registry requirement, and participate 
in the IETF process to get things changed to something more pleasing.  If their 
arguments have merit, they are likely to be picked up and advanced by others 
via the process, and if not, then the asserted misstep is actually a non-issue.

In any case, this is all handled via the existing IETF processes for standards 
and registry policy development; there is no evidence of any need for new or 
additional accountability mechanisms for these IETF processes, particularly to 
the extent that the IETF work predominantly covers technical matters rather than 
"public policy" issues.  That aligns well with the IANA Stewardship transition 
proposal development effort, which is not scoped to include accountability 
mechanisms for "how relevant policies are created, nor the relevant structures 
in which they are created."


Disclaimer: My views alone.