Re: [dnsext] BOF on variants for ICANN San Francisco

John Levine <> Wed, 09 March 2011 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0833B3A6778 for <>; Wed, 9 Mar 2011 14:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.806
X-Spam-Status: No, score=-110.806 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8nK2aYBofpGQ for <>; Wed, 9 Mar 2011 14:12:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BB9703A6768 for <>; Wed, 9 Mar 2011 14:12:39 -0800 (PST)
Received: (qmail 91925 invoked from network); 9 Mar 2011 22:13:55 -0000
Received: from ( by with QMQP; 9 Mar 2011 22:13:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=afed.4d77fba3.k1103;; bh=HQQLN4aH2svZ39X7PydqkV1p/8JTiP24xhi3IKiCfYI=; b=jGNQUmX24TXJSdpLuULZr6OpFDxY1f5+xohdOO3ZagP+q/hp4lje5tBm7ibHL906N+quqBXaHln48+vvy7KQrH+IDlMTMQY1fIRI1SCXKb6CJjxzy2p34UIQaU9RmasT7VrAPkG3Z4SOd87Eyv8iL02AYvcS59ytlQrhmagVn0g=
VBR-Info:; mc=all;
Date: Wed, 09 Mar 2011 22:13:55 -0000
Message-ID: <20110309221355.45036.qmail@joyce.lan>
From: John Levine <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Subject: Re: [dnsext] BOF on variants for ICANN San Francisco
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Mar 2011 22:12:42 -0000

>> I suspect I disagree with the above claim.  Specifically, I think I
>> disagree with "well understood".

I think we understand our technical options pretty well, but not what
problem we're expected to solve.

At ICANN you're likely to run into policy types who say (no doubt in
more words) "spare me the mumbo-jumbo, we just want {set of names}
to work the same."

Once you're done gritting your teeth, this is an educational
opportunity to help people understand the large number of moving parts
that have to be synchonized to get the consistent user experience that
is probably the intutive idea of sameness, e.g.:

If users type various names into their web browser, what should they
expect? Always the same page? How about if some pages are different?
How about if one brings up a page, the rest don't? etc.