Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps

Mark Andrews <marka@isc.org> Thu, 28 May 2015 23:48 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594101ACE86 for <dnsop@ietfa.amsl.com>; Thu, 28 May 2015 16:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.389
X-Spam-Level:
X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_YOUR=2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 74-Tfg_ncvo2 for <dnsop@ietfa.amsl.com>; Thu, 28 May 2015 16:48:13 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECD91ACE7A for <dnsop@ietf.org>; Thu, 28 May 2015 16:48:11 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id DAE541FCC83; Thu, 28 May 2015 23:48:06 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 84A3F16003F; Thu, 28 May 2015 23:48:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4F02C160033; Thu, 28 May 2015 23:48:32 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cLCo0KdVFnGL; Thu, 28 May 2015 23:48:32 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id AEF69160003; Thu, 28 May 2015 23:48:31 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7F2372F955C7; Fri, 29 May 2015 09:48:02 +1000 (EST)
To: Suzanne Woolf <suzworldwide@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <0CB7A66E-B6C9-4FE7-8452-172A5CF48895@gmail.com> <F28C4DE3-12CF-462D-BB55-5A02CA364173@interisle.net> <47EE9472-3E0C-4FA8-A058-8A288675C936@uniregistry.com> <E3483DBB-7F69-4CEB-ACD4-545B3CF7D4E0@INTERISLE.NET> <7FBF3D8B-E340-4540-A8B4-4786FB3E39C4@gmail.com>
In-reply-to: Your message of "Thu, 28 May 2015 11:17:14 -0400." <7FBF3D8B-E340-4540-A8B4-4786FB3E39C4@gmail.com>
Date: Fri, 29 May 2015 09:48:01 +1000
Message-Id: <20150528234802.7F2372F955C7@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/teV0p4-8icO93qQL72RFBwR1SPg>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 28 May 2015 23:48:14 -0000

In message <7FBF3D8B-E340-4540-A8B4-4786FB3E39C4@gmail.com>, Suzanne Woolf writ
es:
> (no hats, as I haven't discussed with my co-chair and AD.)
> 
> On May 27, 2015, at 3:22 PM, Lyman Chapin <lyman@interisle.net> wrote:
> 
> > We don't know each other, but if I may assume that you work for Uniregistry
>  (apologies if I'm jumping to the wrong conclusion from the domain name in yo
> ur email address), you have a clear conflict of interest as a gTLD applicant 
> for "home". Your viewpoint and comments are still valuable, and I mean no dis
> respect when I suggest that you have a conflict; but I hope that when Tim and
>  Suzanne refer to "consensus of the WG" they mean "except for WG participants
>  who have a clear COI".
> 
> For the reasons pointed out by Jim Reid in the next message, I think this hea
> ds in the wrong direction.
> 
> Perhaps more to the point, my experience of the IETF suggests that since cont
> ending interests are a fact of life, and that WG discussion frequently engage
> s vendors, their competitors, their customers, and their vendors all at once,
>  claims about others' conflicts of interest are a poor substitute for address
> ing arguments on the merits (which you get full credit for attempting to do, 
> and can stand on its own).
> 
> > Having heard no (disinterested) objection to putting corp, home, and mail i
> n the special-use name registry defined by RFC 6761, perhaps the WG chairs wo
> uld proceed with a call for adoption of draft-chapin-additional-reserved-tlds
> -02 -
> 
> It would be helpful to me in discerning consensus to separate two different c
> oncepts here.

Can we please stop lumping home/corp/mail as if they need / should
have the same solution.  There presence at the root is clearly the
result of different reasons.  How we deal with there presence at
the root should be different because of that.

The solution space is also much more nuanced that this.

> 1. Delegating home/corp/mail in the root zone would be bad.

Delegating to WHAT would be bad?

* A registry - yes.
* A unsigned empty zone - no.  This breaks the DNSSEC chain of trust
  which would be good for home users as they don't generally already
  have a namespace, not really needed for corporations as they
  should be using a part of their own namespace and does nothing
  for mail as those queries are usually just the label itself.

> 2. Adding home/corp/mail to the special-use name registry would be good.

 
> Again, trying my best to speak as a disinterested observer of the discussion,
>  I've seen little support for such delegations(1). I've seen a couple of argu
> ments that seem to have strong support against such delegations.
> 
> However, that's not the question in front of the WG. The IETF doesn't decide 
> what goes into the root zone. ICANN does, and appears to have already decided
>  (stipulating that not everyone believes them, which strikes me as a separate
>  problem) not to add those names to the root zone.
> 
> The question in front of the WG is whether to propose adding those names to t
> he IETF registry for special-use names(2). I've heard support for that, but I
> 've also heard a number of objections to such additions, and I'm having troub
> le telling how much the support for (2) is really support for (1) or vice ver
> sa.
> 
> It remains less than obvious to me what outcome is being sought here. I first
>  thought it was to influence the body that *does* decide what goes into the r
> oot zone against a possible future change in policy, but it's also been repea
> tedly asserted that no, the proposal is motivated by operational consideratio
> ns.
> 
> I realize I may be dim, but what operational impact is sought here?  What cha
> nge in server or resolver configuration are administrators expected to make? 
> Is there some other possible source of name collisions besides a change in th
> e root zone that we can or should be guarding against? Given that the problem
>  people seem concerned about developed entirely outside of any action by the 
> IETF, how does the IETF acting now help?
> 
> I understand the argument that the IETF can and should prevent such a misstep
>  by ICANN, so reiterating it won't help me. 
> 
> 
> thanks,
> Suzanne
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org