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

[Warren Kumari <[e-mail]>]

On Thu, Oct 29, 2015 at 9:27 AM Joe Abley <[e-mail]> wrote:

> 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.
>
>
Thanks again to the design team for writing this....

Before I forget, here are some readability / grammar nits. I have some more
substantive comments too, but I wanted to send these over before I
accidentally close that buffer :-)

================
Abstract

......

[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
[O] reservations, that is, particular
[P] reservations; that is, particular
[R] grammar
...
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.
....
1.  Terminology

Clear and unambiguous use of terminology is important for the clear
formulation of any problem statement.  The DNS protocol suffers from
imprecise and overloaded terminology (e.g. see
[I-D.ietf-dnsop-dns-terminology]) without confusing matters further
with terms and concepts from other naming systems that are similar,
but different.

[o] The DNS protocol suffers from
imprecise and overloaded terminology (e.g. see
[I-D.ietf-dnsop-dns-terminology]) without confusing matters further
with terms and concepts from other naming systems that are similar,
but different.
[P] The DNS protocol suffers from imprecise and overloaded terminology
(e.g. see
[I-D.ietf-dnsop-dns-terminology]). The use of terms and concepts from other
naming systems that are similar (but different) simply confuses matters
further.
[R] readability -- I *think* this is what was meant?
In the interests of clarity, the following terms used in this
document are to be interpreted as follows:

.....
4.  Architectural considerations

The first thing to consider in this discussion is that not all names
(or domain names) are par of the Domain Name System.  See [ID-lewis-
[O] are par of the
[P] are part of the
[R] typo

domain-names] for an in-depth discussion on this topic.
....


LOCAL is used by the Multicast DNS protocol specified in [RFC6762]
which is similar in some respects to the DNS, but which uses
different well-known port number and is limited to a particular
[O] different well-known port number
[P] a different well-known port number
[R] grammar

multicast scope;
....

It should also be noted that there are other choice than using the
[O] there are other choice
[P] there are other choices
[R] grammar

most significant label for a protocol switch.  In particular, a
proposal to move those protocol switches under a specific top level
domain has been discussed (.ALT).  If that architecture choice is
made, some of the questions listed in the sections bellow would
[O] bellow
[P] below
[R] spelling

become moot.

5.  Technical considerations
.....
Such documents might well be opaque to many
readers ([RFC6762] is a seventy-page protocol specification, for
example, which is arguably not the most expressive way to set
[O] expressive
[P] effective
[R] optional; might be a better word choice?
expectations of non-technical end-users).


At the time of writing, the DNSOP working group charter does not
clearly indicate that DNSOP is the proper venue for the evaluation to
be carried out, although it also says that matters regarding the
namespace are on topic.  Also, as pointed out in section 3.2), we are
[O])
[P]
[R] no matching open parenthesis


6.2.2.  Technical criteria

Regardless of the actual name being proposed as protocol switch, it
is also not clear what technical criteria should the evaluation body
use to examine the merit of an application for such a reserved name/
[O] what technical criteria should the evaluation body
use
[P] what technical criteria the evaluation body should use
[R] readability

===========



> 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
> >
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>