I won't be in Berlin, but I think this draft deserves discussion. It's simple, focussed on the problem statement side.
[ I'm speaking from left field, since I think the best course right now is to shut the process down, but I don't see a problem-statement as a problem in that light: all the problems solve nicely if we shut the door! ] I think the one major issue (for me at least) is that the implication the IAB through draft/RFC process *can* assign a name remains. I don't personally think it makes sense to leave open the option to bypass ICANN process. I think you might want to state a problem as something like: "how can we best codify competing peer SDO process, into what the IAB regards as a proper sequence of events to allow IETF requests to be handled appropriately by ICANN" Because without that, you leave the implication open that names can just be taken, irrespective of what people in ICANN might say. And, whilst they aren't technical standards, there are standards in how they decide to delegate names. Your 'assertion of authority' item goes close maybe: If we accept the authority token moved, then we should recognize a process which doesn't respect the authority token handoff is .. broken. -G On Thu, Jun 30, 2016 at 12:32 PM, Ted Lemon <[email protected]> wrote: > Apologies for taking so long to get this out. Despite the delay, I still > believe that this document represents a better starting point for the > discussion of the special-use name problem. > > I believe that the right way to approach this problem is to try to > enumerate, without judgment, all of the problems that people are aware of > that are not problems with potential solutions. > > Having done so, we can then enumerate, again without judgement, the > potential solutions to each problem, which will likely be mutually > contradictory. > > Having done _that_, then I think we will be in a position to make a fully > informed decision from the set of alternatives that we have identified, > based on the end result that we want to achieve or avoid. > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Wed, Jun 29, 2016 at 7:15 PM > Subject: I-D Action: draft-tldr-sutld-ps-01.txt > To: [email protected] > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Special-Use Names Problem Statement > Authors : Ted Lemon > Ralph Droms > Warren Kumari > Filename : draft-tldr-sutld-ps-01.txt > Pages : 15 > Date : 2016-06-29 > > Abstract: > The Special-Use Domain Names registration policy in RFC 6761 has been > shown through experience to present unanticipated challenges. This > memo presents a list, intended to be comprehensive, of the problems > that have been identified. In addition it reviews the history of > Domain Names and summarizes current IETF and non-IETF publications > relating on special-use domain names. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tldr-sutld-ps-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-tldr-sutld-ps-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
