Subject: [DNSOP] update on work item regarding special use names (RFC 6761)

From: Suzanne Woolf <[email-masked]>
Date: Thu, 11 Feb 2016 20:48:37 -0500

Colleagues,

The chairs have been working through concerns and issues around both the substance and the process related to special use names after the approval of .onion and our meeting at IETF 94 in Yokohama. 

We note the following:

The initial approach to further progress was to name a "design team" to work on a problem statement. There was no intention that the results of this initial group would have any special standing, or limit contributions by others; it was a way of bootstrapping a focused effort.

This approach hasn't worked out exactly as we'd expected-- it confused people without making as much progress as we'd hoped. In particular, the discussion that followed the initial problem statement draft did not provide the guidance we sought on what additional resources might be needed for the design team to make further progress. In addition, we have lost one of the initial authors of the problem-statement draft-- Joe Abley has had to shift his primary focus in support of his day job. 

But we did get an internet-draft out of it, and some good discussion of how it might be improved. We think this provides a solid basis for further productive discussion.

We're proceeding as follows:

We've asked the authors of http://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/ to produce a revised version, to be based on input received in Yokohama and on the mailing list. Joe is not available, but Peter Koch, Alain Durand, and Ralph Droms are working on it. 

The -01 will be appearing shortly, and we would like discussion/review on it with the expectation that if the WG feels it's covering the main points, we'll adopt it as a WG draft.

Adoption of the draft is a WG decision, and the IETF process requires that everyone be heard. So there will be plenty of opportunity to assess the draft, on the mailing list and in Buenos Aires. 

Once we've seen whether the WG wants the problem statement draft as a WG document, we will decide how to proceed, with or without an expanded "design team" to do further work on the problem statement.

best regards,
Suzanne & Tim

---

From: hellekin <[email-masked]>
Date: Mon, 22 Feb 2016 15:55:36 +0000

On 02/12/2016 01:48 AM, Suzanne Woolf wrote:
> 
> http://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
>

Hello,

This ID seems to require the definition of a new registry, and Section 6
to suggest how this would be used.  I think this goes way beyond what
needs to be done in order to revise RFC6761.  Another registry (for
protocol switch) is not solving anything.  Instead, whether the TLD
operates a protocol switch can be documented in the existing registry:
creating a new registry for this would only sidetrack the problem of
registering new Special-Use Domain Names without solving any issue with
RFC 6761.

*

Editorial notes:

In section 3, the term "impact" is used abusively to replace the
original "considerations".  Considerations are welcome, impact should be
avoided.

"[Answers to these seven questions] are inadequate for making the
determination whether a particular domain name qualifies as being
special in the first place." -> This statement should be followed by a
demonstration how this situation is factual, otherwise it's irrelevant.

Section 4 has a typo: "are par of" should read "are part of".

Section 4 may mention NSSwitch?

Section 4 has a typo: "we are actually building a catalog of all top
level domains that explain which are are switches." -> should read "that
explains".

"... has been discussed (.ALT)." -> Requires reference.
Note: .ALT does *not* apply generally, but only to those "alternate
domains" that *do not require global uniqueness* of names.

Therefore "If that architecture choice is made, some of the questions
listed in the sections bellow would become moot." is moot.

Section 5: "In the case of [I-D.ietf-dnsop-onion-tld], leakage" ->
Update reference to RFC 7686. (Also in Section 6.2.1)

Section 6.2.2: "For example, is large scale prior deployment an
acceptable criteria?" -> This is a bad example, as lengthy discussions
about it illustrate in the case of a peer-to-peer network where "large
scale deployment", besides being entirely subjective, is also
non-measurable.

Thanks for the "Pithy Quotes from History" :)

Regards,

==
hk