Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa

Ted Lemon <mellon@fugue.com> Thu, 23 March 2017 21:01 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BA5131671 for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 14:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 VGGwTwML4uFU for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 14:01:40 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3310129C16 for <dnsop@ietf.org>; Thu, 23 Mar 2017 14:01:40 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id r45so186445024qte.3 for <dnsop@ietf.org>; Thu, 23 Mar 2017 14:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/K/P+5kEoWmW2GXXFcl2Ly9Y4suCSzmBQxKPE/J1G00=; b=Xb46USba/aNP29RzIAB260kPCKszeq2UrpEfMjSHPNvLxgdV8Mh1tA2bb/klwZXhfy 36E4Hb9VabEQs0+X9Swb+pAZbQdsQhl88JSu4nGaroK9mOwLCMDZpfuhRr3vT/vLS8JT GQ5S5heraGTYQMg8FvagNdOt2jWp9wvxnL2FTFzf0G5hujle/Oouo5MOP3SZ6zP4sVus aHvV17HAzLmOoB+S8VItuQrZ/p0eWY6JUY9he/+rY8sNFiumh8c3DqhmY7Hxs5G930xW aIc49LqE/dcK753i+tuYuQeaMTYvqal2+cKdFa6mwsUY4aNl+nGQGls2s0waK1WcR3uH Jq3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/K/P+5kEoWmW2GXXFcl2Ly9Y4suCSzmBQxKPE/J1G00=; b=aHnofGR8ojTSD8tA/z41KzxR0kWEfxymor8+RrLRMIuvG0/bVJGh+pvX/I8Xy8Wyae V8GW54bRzZciedM6vvRcmQHb3NwQOSQDxd/amOLBHBQjs1szcFCmZvhJw62f6NOeGVNp MpTWLWpLrv3LIh5OwdhJ2CXo+G7Cch8bQyCa+SyJ1Rk/Ko54KqH6UGXjHcg1XhFpwQi8 mQD3QhpOaFxQsYRbrdcbjBw0Y6POpnVqUmSaLLxvFJOEII0FhSf2sa/M5DE4y7dm6CV1 RXyA81lYOe2cTEZJj7mINqV31MHXobB0eEXzY4us5MBqk19lfSE/lG8TJXCQAN+gigmi 5emA==
X-Gm-Message-State: AFeK/H1f7o7r+vLFKpCVlzHbVG1kCweqT0Dep5+gwMua/266ngavH6M2q+HLWOceHNYW/Q==
X-Received: by 10.200.34.77 with SMTP id p13mr4457137qtp.22.1490302899585; Thu, 23 Mar 2017 14:01:39 -0700 (PDT)
Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e16sm116840qkj.64.2017.03.23.14.01.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 14:01:38 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <88136264-A06D-4A46-9369-0F0059E633D9@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_89091CA5-3012-4DF0-84F8-DD50615493FB"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 23 Mar 2017 17:01:36 -0400
In-Reply-To: <AB3C9BCC-AFF5-43E9-8312-ADFE28B75D0B@isoc.org>
Cc: Paul Wouters <paul@nohats.ca>, dnsop <dnsop@ietf.org>, Ray Bellis <ray@bellis.me.uk>
To: Dan York <york@isoc.org>
References: <20170323042741.79108.qmail@ary.lan> <2C6B4EB6-D0F0-44A8-95E4-68DF32244639@fugue.com> <20170323163205.GD19105@mx4.yitter.info> <500af1ed-5425-4452-ad8e-c2d511ee738d@bellis.me.uk> <850A8729-8762-4375-90EF-50CDF4AC232E@gmail.com> <alpine.LRH.2.20.999.1703231351490.2262@bofh.nohats.ca> <a6e98737-b426-a67b-efe7-3603c531afcb@bellis.me.uk> <alpine.LRH.2.20.999.1703231412130.2262@bofh.nohats.ca> <AB3C9BCC-AFF5-43E9-8312-ADFE28B75D0B@isoc.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NC9ItkAu7z_UpVhSmmSDJki5BK8>
Subject: Re: [DNSOP] Homenet implementation plans by vendors? Re: .arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 21:01:44 -0000

On Mar 23, 2017, at 4:11 PM, Dan York <york@isoc.org> wrote:
> I ask in part because if the IETF did decide to go down the route of interacting with ICANN to make special exceptions in the root zone, these are exactly the kind of questions I could see people at ICANN asking.  It would also speak to the timeframe question. If there are people clamoring for this functionality, that might raise its priority.

I can see ICANN people asking these questions too.   However, I wonder if this is really the right approach.   If the IETF has the right under the MoU to ask for root delegations, then it seems to me that the IETF should just be allowed to ask.   There should obviously be a process, and the IETF should not ask frivolously, and certainly shouldn't ask as a way to bypass the gTLD process.   But ultimately it doesn't make sense to me for ICANN to ask this question.

Either IETF can ask for technical-use TLDs to be delegated, or it can't; the question from ICANN's perspective ought to be "(a) is this a technical use?  if not, IETF has no special access.   if so, (b) is the name in dispute?   If so, IETF can't have it.   If not, IETF can have it."   Of course, I'm sure that's hopelessly naive, but the point is that we need to have this conversation and figure this out.   This is true whether the IETF goes ahead with .homenet or not, so whether this is hard or not really shouldn't be a determining factor in whether we try to get .homenet delegated.

That said, of course you can ask this question _in the IETF_ and maybe it's a good question.   The answer is that there is a lot of _interest_, but it's not clear to me that this interest will transform immediately into product on the shelf.   My expectation is that it will start out in open source distros, and in a few high end boxes, and trickle down.   I know various vendors and operators have expressed strong interest in this in the past, but the difficulty of making any forward progress at all within the IETF (this being an example) has been discouraging for them.

So at this point I can't promise that if we build it they will come; they are already here, but they are a bit frustrated, and that could have a negative impact on deployment.   But we wouldn't be trying to build this if we didn't think it was worth building.