[DNSOP] Fwd: New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

["Joe Abley" <[e-mail]>]

Hi all,

Our esteemed chairs have recently outlined a path forward for addressing 
the IESG's concerns relating to the implementation of RFC 6761, 
triggered by the experience of assessing RFC 7686 ('The ".onion" 
Special-Use Domain Name'). The IESG's concerns are summarised in 
<http://www.ietf.org/blog/2015/09/onion/>.

Paraphrasing Suz and Tim (please correct me if I mis-speak) the approach 
to be taken in this working group is to try to achieve consensus on a 
problem statement as a first step, following which we will be in better 
shape to have focused discussion of potential solutions. A call for 
volunteers was made to augment an earlier ad-hoc design-team design-team 
to write up that problem statement, consisting of Alain Durand, Peter 
Koch and me, and I gather that some eligible thrill-seekers have already 
put their names forward to join us.

A very rough first cut of a problem statement was submitted hurriedly 
before the 00 cut-off deadline in order to try and move this 
conversation forward (see below). This text doesn't even represent 
particularly strong consensus amongst Peter, Alain and me, never mind 
the yet-to-be-fully-formed design team or the working group as a whole, 
but it's a starting point. An earlier rendering of the text with 
different organisation (that was not submitted) can be found at 
<https://github.com/ableyjoe/draft-adpkja-dnsop-special-names-problem>.

I take full, personal responsibility for the gratuitous definition of 
"aardvark", and the ancient, historical quotes from the namedroppers 
archive that you'll find in appendix A. You're welcome.

I will unfortunately not be in Yokohama next week, but I would encourage 
anybody interested in the general problem space to discuss it on this 
list. I think it's reasonable to consider the current and future design 
team victims to be a secretariat for this discussion, and the content of 
any consensus on this needs to come from an open and transparent 
discussion here, in the working group.


Joe

Forwarded message:

> From: [e-mail]
> To: Joe Abley <[e-mail]>, Peter Koch <[e-mail]>, Peter Koch 
> <[e-mail]>, Alain Durand <[e-mail]>
> Subject: New Version Notification for 
> draft-adpkja-dnsop-special-names-problem-00.txt
> Date: Mon, 19 Oct 2015 16:26:08 -0700
>
>
> A new version of I-D, draft-adpkja-dnsop-special-names-problem-00.txt
> has been successfully submitted by Alain Durand and posted to the
> IETF repository.
>
> Name:		draft-adpkja-dnsop-special-names-problem
> Revision:	00
> Title:		Problem Statement for the Reservation of Top-Level Domains in 
> the Special-Use Domain Names Registry
> Document date:	2015-10-19
> Group:		Individual Submission
> Pages:		12
> URL:            
> https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
> Htmlized:       
> https://tools.ietf.org/html/draft-adpkja-dnsop-special-names-problem-00
>
>
> Abstract:
> The dominant protocol for name resolution on the Internet is the
> Domain Name System (DNS).  However, other protocols exist that are
> fundamentally different from the DNS, but which have syntactically-
> similar namespaces.
>
> When an end-user triggers resolution of a name on a system which
> supports multiple, different protocols for name resolution, it is
> desirable that the protocol to be used is unambiguous, and that
> requests intended for one protocol are not inadvertently addressed
> using another.
>
> [RFC6761] introduced a framework by which, under certain
> circumstances, a particular domain name could be acknowledged as
> being special.  This framework has been used to make top-level domain
> reservations, that is, particular top-level domains that should not
> be used within the DNS to accommodate parallel use of non-DNS name
> resolution protocols by end-users and avoid the possibility of
> namespace collisions.
>
> Various challenges have become apparent with this application of the
> guidance provided in [RFC6761].  This document aims to document those
> challenges in the form of a problem statement, to facilitate further
> discussion of potential solutions.
>
>
>
>
> 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.
>
> The IETF Secretariat
>