Re: [Ianaplan] A draft for your review

JFC Morfin <> Sun, 02 November 2014 12:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D17FC1A878E; Sun, 2 Nov 2014 04:52:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.83
X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6j8mFuXID4wc; Sun, 2 Nov 2014 04:52:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BFD01A8789; Sun, 2 Nov 2014 04:52:15 -0800 (PST)
Received: from ([]:41507 by with esmtpa (Exim 4.82) (envelope-from <>) id 1Xkudg-0005Po-DE; Sun, 02 Nov 2014 04:52:12 -0800
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sun, 02 Nov 2014 13:52:05 +0100
To: Suzanne Woolf <>, Marc Blanchet <>
From: JFC Morfin <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: user confirmed/virtual account not confirmed
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: Sun, 02 Nov 2014 12:52:17 -0000
Message-ID: <>


IANAL but I know that contracts are protocols between 
people/organizations. Asking engineers to discuss contracts seems as 
sure as asking lawyers to write a technical standard RFC.

At 16:51 01/11/2014, Suzanne Woolf wrote:
>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.

I am afraid I do not see in which manner having mechanisms to achieve 
something makes it so that all of this will be achieved. RFC 2860 is 
clear about this: in case of a standing disagreement, RFC 2860 
Section 4.3, Note: "In the event ICANN adopts a policy that prevents 
it from complying with the provisions of this Section 4 with respect 
to the assignments described in (a) - (c) above, ICANN will notify 
the IETF, which may then exercise its ability to cancel this MOU 
under Section 2 above."

This language does not permit ICANN to be accountable concerning the 
NTIA's demand:  "Maintain the security, stability, and resiliency of 
the Internet DNS". The IETF has the ultimate capacity of decision 
and, therefore, responsibility (actually ISOC has it through the 
appeal process).

>At 17:52 01/11/2014, Andrew Sullivan wrote:
>But that didn't happen, which suggests to me that the division of 
>labour, again, is working.

IMHO, to make the past the guarantee of your future is to ensure that 
you will be fooled.

>At 18:53 01/11/2014, David Conrad wrote:
>Given the IETF has delegated administration via RFC 2860, I would 
>have thought it useful to formally include the delegatee in 
>discussions related to the resource (either domain names or IP 
>addresses) being discussed, not just have the decision be solely 
>dependent on the IESG's opinion.

David, is this truly the "status quo" :-)?

If I understand you, what ICANN wants is to control things through RFC 2960bis.

I have 255 classes that I can use and IETF has a few thousand that it 
can freely affect. Perhaps it is time to contract that the ICANN/NTIA 
"IN" Class is the undisputed ICANN one.

If there are too many or buggy TLDs in the root of that class, users 
will know about it and competition will play its role.