Re: [Ianaplan] A draft for your review

Suzanne Woolf <> Sat, 01 November 2014 15:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 082A41A8939 for <>; Sat, 1 Nov 2014 08:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Fvfw7joIAGl for <>; Sat, 1 Nov 2014 08:51:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F5F01A8934 for <>; Sat, 1 Nov 2014 08:51:39 -0700 (PDT)
Received: by with SMTP id x3so7280153qcv.21 for <>; Sat, 01 Nov 2014 08:51:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eTLNvjGhCbA2h2fDBU3kbAFxFV9SfkssbRPtBvy7pi0=; b=IA2XGT76GECWKBYDmddLuhZ2ASZ39J7WPN1uhy0IcSXcueZbkzkuUodsh5uN2BeshH p8ctI9clc2QPvqr0yjq2xjAl7FG8ZgiMEDha/YJcB2+H5mRbWfzCH18JhFBZoDN2Ug4O Fk11ZGIr/6fvAN2018wLVfXboemq4ETTxCzMF+cEFaYLbKbFmeTjQbpAPlB5IzjLTuPE q0K3SJxk2ovQPUM32fize/HmNGOfGqpckPE0g7KMVoFO8BtRPC5vDGI6hiVlIPPW4b63 /2njUJdJcvIiRO2rgrDwGG5gKnionlYrDXCXo36CIBYennAwhZlGvygRyWEVhTGFbBIu xYQQ==
X-Received: by with SMTP id 3mr47551894qax.79.1414857098300; Sat, 01 Nov 2014 08:51:38 -0700 (PDT)
Received: from ?IPv6:2601:6:3a80:77e:3109:ed09:a127:e7dc? ([2601:6:3a80:77e:3109:ed09:a127:e7dc]) by with ESMTPSA id 78sm12334541qgp.2.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 08:51:37 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <>
In-Reply-To: <>
Date: Sat, 01 Nov 2014 11:51:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Marc Blanchet <>
X-Mailer: Apple Mail (2.1510)
Cc:, David Conrad <>, Eliot Lear <>
Subject: Re: [Ianaplan] A draft for your review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Nov 2014 15:51:42 -0000


I think we have two almost-separate considerations here: how the coordination on topics like "technical use" names is done and how it could be improved; and what it's necessary to say on the subject in the ICG response document.

On the first-- as already pointed out, we've got existing IETF authority (the MoU) and process (RFC 6761, with all the accompanying machinery of writing drafts and making the case for a change in the relevant registry under its rules). We've also got the machinery to change that process if it's inadequate: normal IETF process for updating or obsoleting an RFC, a WG whose charter includes such namespace issues (DNSOP), and an IAB liaison statement sent to ICANN specifically on this topic, also under IETF process and an existing liaison relationship ( I can speak as DNSOP co-chair that we're interested in input, because applying RFC 6761 has already proven problematic and people keep writing drafts that attempt it. And I can't speak for the IAB, but response to the liaison statement would probably be welcome too.

If people feel coordination on a specific  "technical use names" issue is needed, there are mechanisms in place today to do it. If people feel better coordination process is needed (such as might follow from a clearer definition of "technical use names"), there are mechanisms in place today to create them too, and even recent suggestions (the DNSOP re-charter, the IAB liaison statement) that people might want to consider invoking them. 

On the IANAPLAN draft specifically: none of the existing coordination mechanisms depend on NTIA or the IANA functions contract, and I humbly submit there's no reason to expect that to change. Documenting the current situation, including the existence of process for changing it, is all we need to do.

The current draft says:

"It is important to note that the IETF includes anyone who wishes to
   participate.  Staff and participants from ICANN or the Regional
   Internet Registries (RIRs) regularly participate in IETF activities.

   o  The IETF has specified a number of special use registries with
      regard to domain names.  These registries require coordination
      with the Generic Names Support Organization (GNSO).  We already
      perform this coordination.[RFC6761]"

My suggested edit:

* I favor preserving the reference to participation in the IETF by ICANN and RIR staff and community participants; it strengthens the point that they are part of the coordination we're discussing in this section.

* I suggest new text for the first bullet point:
	"The IETF has specified a number of special use registries with regard to domain names.  These registries require coordination with ICANN as the policy authority for the DNS root [RFC2860], including community groups that are responsible for ICANN policy on domain names such as the GNSO and the ccNSO.  There are already mechanisms in place to perform this coordination, and the capacity to modify them to meet new conditions as they might arise." [RFC6761,]

(holding assorted roles in both the IETF and ICANN 
universes,  but speaking for myself alone)

On Nov 1, 2014, at 10:07 AM, Marc Blanchet <> wrote:

>> Le 2014-11-01 à 01:50, David Conrad <> a écrit :
>> Eliot,
>> On Oct 31, 2014, at 10:44 PM, Eliot Lear <> wrote:
>>> On 11/1/14, 6:42 AM, David Conrad wrote:
>>>> The same ones in which the folks most active in creating top-level
>>>> domains and to whom the administration of the domain space was
>>>> delegated were unaware?
>>> This is not true for everyone in that community, but to be sure we can
>>> always do a better job at making people aware of that.
>> I think you might be missing my point.
>> IIRC, part of this thread (the part Avri was commenting on) was discussing whether there were cases in which coordination was necessary between functions.  I believe RFC 6761 is an example in which coordination was necessary and did not occur. Another is between the operational/RIR community and the IETF related to TLAs. I believe there are others. And that is with a unified IANA. The problem is that it is difficult to know beforehand whether or not coordination is necessary and/or whether the coordination has been sufficient. If IANA is to be functionally decomposed, I believe care must be taken to ensure that coordination can be done effectively.
> I agree.  And my take is that most people would agree. The question is how to appropriately put this in text. And in some ways, that exact text is to be coordinated between the parties. circle…
> Marc.
>> Regards,
>> -drc
>> _______________________________________________
>> Ianaplan mailing list
> _______________________________________________
> Ianaplan mailing list