Re: [Ianaplan] Trial balloon: suggested text

"Richard Hill" <rhill@hill-a.ch> Wed, 19 November 2014 08:47 UTC

Return-Path: <rhill@hill-a.ch>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C491ACF88 for <ianaplan@ietfa.amsl.com>; Wed, 19 Nov 2014 00:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.692
X-Spam-Level:
X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 jelC59RLmpb2 for <ianaplan@ietfa.amsl.com>; Wed, 19 Nov 2014 00:46:53 -0800 (PST)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [IPv6:2001:1600:2:5:92b1:1cff:fe01:147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798831A0119 for <ianaplan@ietf.org>; Wed, 19 Nov 2014 00:46:53 -0800 (PST)
Received: from Timea ([212.203.112.169]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id sAJ8kofM007484; Wed, 19 Nov 2014 09:46:51 +0100
Message-ID: <42A72FFC82DF4444A6E9D541836434DA@Timea>
From: Richard Hill <rhill@hill-a.ch>
To: "Peterson, Jon" <jon.peterson@neustar.biz>, Milton L Mueller <mueller@syr.edu>, "Leslie Daigle (TCE)" <ldaigle@thinkingcat.com>
References: <546B8544.5070109@thinkingcat.com> <79C41CC5-8B1B-49C5-891C-904B4B32A6D7@vigilsec.com> <D090CF36.13AC1B%jon.peterson@neustar.biz> <546B945D.6050501@cisco.com> <D090D4E6.13AC4C%jon.peterson@neustar.biz> <8ec9509e98174fbda96ca86b6b51a0d3@EX13-MBX-13.ad.syr.edu> <D0913EEE.13AE28%jon.peterson@neustar.biz>
Date: Wed, 19 Nov 2014 09:46:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/wbiwrRrMa1Sdcn7Tbq_2YU5p7V8
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] Trial balloon: suggested text
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Nov 2014 08:47:03 -0000

Dear  Jon,

Thank you for this.  I think that your comments are very helpful because 
they help to clarify the differences in points of view.  Please see embedded 
comments below.

Thanks again and best,
Richard
----- Original Message ----- 
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "Milton L Mueller" <mueller@syr.edu>; "Leslie Daigle (TCE)" 
<ldaigle@thinkingcat.com>
Cc: <ianaplan@ietf.org>
Sent: Wednesday, November 19, 2014 4:47 AM
Subject: Re: [Ianaplan] Trial balloon: suggested text


>
> A bit of the ol' inline below.
>
> On 11/18/14, 6:05 PM, "Milton L Mueller" <mueller@syr.edu> wrote:
>
>>Jon:
>>
>>> -----Original Message-----

SNIP

> I suspect most of our disputes really derive from the difference in
> philosophy illustrated by this point above. Since we're entertaining the
> "hostile" cases here,

Not necessarily hostile.  ICANN is subsidizing the IANA function: it costs 
money to run it, but the IETF does not pay for it.  ICANN is, at present, 
constrained to provide the function at no cost by its contract with NTIA:

Absent that contract, ICANN could decide that it does not wish to provide 
that function for free, or even that it does not wish to provide that 
function at all.

Or ICANN could cease to exist (unthinkable now, but how many of us thought 
that Wang or Digital Equipment would cease to exist?).

>let me try to put this in the starkest, most
> confrontational terms. I believe that any value that exists in the
> protocol parameter registries exists because we (the IETF) choose it as a
> place to store values. If an operator of the protocol parameter registry
> insisted on an arrangement that was not acceptable to us, we would simply
> store parameters elsewhere, thereby eliminating any value in the old
> protocol parameter registry.

That is correct.  Way back when, and I believe on a different list, Miles 
made the point that the protocol parameters function is not rocket science 
and similar things are done by and for many other standards making bodies, 
such as ISO.

That's correct, and, as far as I  know, most of those other standards making 
bodies don't have any particular agreements with whoever does the clerical 
equivalent of the IANA function.  It is either done by the organization's 
own secretariat, or by some other organization that does it in exchange for 
fees, or, in some cases, at no cost.

The situation is different here because the US government asserted its 
authority to make contractual arrangements regarding the performance of the 
clerical function.  As a consequence, the intellectual property, including 
the mark IANA and the domain name IANA.ORG were transferred to ICANN.

In analogous cases for other standards making organizations, the 
intellectual property is owned by the standards making body, so an 
outsourced clerical operator is obliged to comply with the instructions of 
the standards making body.

That is not the case here: absent a new contract, there are no legal 
constraints on ICANN.

Back when ICANN was created, the IETF didn't have sufficient funding to 
envisage performing the function in its own secretariat.

Today, the IETF does have sufficient funding to envisage performing the 
function in its own secretariat.

I can well understand that the IETF is happy to have someone else perform 
the function at no cost, but, in my experience, there ain't no such thing as 
a free lunch, so I'm wary.


>They would lose everything, we would lose
> nothing.

The IETF might lost the ability to refer to the function as IANA, and it 
might not be able to continue to use the IANA.ORG domain name.  And it might 
not get the service at no cost.

SNIP

>
> The harm being done? Starkly and confrontationally, I think bullet 3 reads
> like an invitation for a protocol parameter registry operator to
> completely misconstrue their relationship to the IETF and to impose fees
> on us as soon as the NTIA steps aside,

I agree.  I will propose something different for 3 in the trial balloon.

SNIP