On May 28, 2015, at 11:17 AM, Suzanne Woolf wrote: > (no hats, as I haven't discussed with my co-chair and AD.) > > On May 27, 2015, at 3:22 PM, Lyman Chapin <ly...@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 >> your 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 disrespect 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 > heads in the wrong direction.
Yes, I agree; I reacted inappropriately when it appeared that the only "don't reserve these names" comment came from someone who works for Uniregistry. Apologies to the WG. > Perhaps more to the point, my experience of the IETF suggests that since > contending interests are a fact of life, and that WG discussion frequently > engages vendors, their competitors, their customers, and their vendors all at > once, claims about others' conflicts of interest are a poor substitute for > addressing 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 in >> the special-use name registry defined by RFC 6761, perhaps the WG chairs >> would 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 > concepts here. > > 1. Delegating home/corp/mail in the root zone would be bad. > 2. Adding home/corp/mail to the special-use name registry would be good. I agree that these are different assertions, but they are not assertions about different concepts. (1) expresses the risk of instability associated with changing the way in which specific TLD names that have become deeply embedded in existing practices are resolved by the global DNS. (2) refers to the suitability, or optimality, of a specific mechanism for dealing with (1). If you are setting these up as if (1) is the purview of ICANN, and (2) is the purview of the IETF, then I think that you are creating a false dichotomy. I'm of course aware that not everyone likes the mechanism created by 6761, and not everyone thinks that the 6761 mechanism is the best way to accomplish the goal of permanently preventing specific strings from being delegated as TLD names. (I also recognize Mark's "delegating to WHAT?" - there's a lot of detail lurking behind the language we've been using to discuss this, and yes, those details are different for corp, home, and mail, which have been bundled as if they were equivalent.) But this is the tool that we have, so it's the tool we've used. > 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 > arguments 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. I believe that your effort to frame the question as "who decides what goes into the root zone?" is misguided. ICANN's decisions about which new gTLDs to allow into the root are policy decisions - the new gTLD program is an enormous policy machine designed and operated specifically for this purpose. The IETF's interest in operational stability is orthogonal to ICANN's policy machinery. As John says, the IETF can say "this specific string must not be a TLD name" because it would destabilize the operating Internet without infringing ICANN's privilege to operate its policy machinery with respect to gTLDs in general. I'm bewildered by your repeated assertion that the problem with ICANN's decision "not to add those names to the root zone" is that "not everyone believes them" - as if it were simply a matter of trust. It's not. ICANN's decision, which I trust completely, is a *policy* decision. A 100% trustworthy policy decision can be changed, with no forfeiture of trust, if the policy on which it is based changes. ICANN's processes and criteria for policy development and change are different from those of the IETF. Not better, or worse, or more believable, or less believable - just different. > The question in front of the WG is whether to propose adding those names to > the 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 > trouble telling how much the support for (2) is really support for (1) or > vice versa. I haven't heard objections to (2); but as I've already said, (2) concerns the use of an IETF Proposed Standard mechanism to deal with (1), so I don't understand the distinction implied by "(2) is really support for (1)" - ? > It remains less than obvious to me what outcome is being sought here. The addition of three names to the special-use name registry defined by RFC 6761 :-) Sorry, couldn't resist... > I first thought it was to influence the body that *does* decide what goes > into the root zone against a possible future change in policy, but it's also > been repeatedly asserted that no, the proposal is motivated by operational > considerations. See below; I don't agree with the way in which you are framing the question. > I realize I may be dim, but what operational impact is sought here? What > change in server or resolver configuration are administrators expected to > make? Is there some other possible source of name collisions besides a change > in the 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? None of those questions is relevant to the request to proceed with a call for adoption of draft-chapin-additional-reserved-tlds-02. > I understand the argument that the IETF can and should prevent such a misstep > by ICANN, so reiterating it won't help me. I don't think that the IETF can or should be in the business of trying to prevent an ICANN misstep. That's not what this is about. The point of an IETF decision to add corp, home, and mail to the special-use names registry would not be "to guarantee that no future ICANN policy change could lead to their delegation as TLD names." It would be to permanently reserve them for the special uses to which they have already been put (a fact on the ground, not a value judgement about whether they "should" or "should not" have been put to those uses), thereby preventing the unstable consequences of delegating them as gTLDs. It's not about ICANN - it's about the interest of the IETF in operational stability. - Lyman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
