[Inip-discuss] some comments on draft-lewis-domain-names-03

[Suzanne Woolf <[e-mail]>]

Hi,

Gearing up to take related issues in Berlin….as we discussed in the ARCING BOF in Buenos Aires, it still seems the topic of "domain names" and related identifiers deserves to be considered in a larger context than the DNS, and this draft is a strong step in that direction. So I'm commenting here in hopes of encouraging others to do the same and encouraging Ed to keep working on it.


Suzanne
==============
Some notes on draft-lewis-domain-names-03.txt:
Suzanne Woolf
July 4, 2016


These occur as I read through the document, so in linear order, if not
necessarily orderly. I've tried to include enough context that the
reader can tell what I'm responding to.

On "NOTE TO RFC EDITOR AND REVIEWERS"

* Not sure this belongs on DNSOP; ARCING or INIP-DISCUSS. I'm sending
  my comments to INIP-DISCUSS because I'd like to see the IAB adopt
  this draft.

Sec. 1.1: 

* Not sure I'd describe the relationship between RFC 2860 and RFC 6761
  as a "conflict." For example, some people believe there's no
  conflict if we define the difference between "names in the DNS root
  zone" (or "DNS names" as a subset of "domain names") and "domain
  names".

* "The beneficiaries of such work include both the developers of
  software that makes use of names and identifiers." Only one of the
  "both" is specified. Other possible parties who are interested
  include users and protocol developers, so maybe the "both" covers
  more than two :-)

Sec. 1.2:

* It seems to me that the document also includes some considerations
  for how the clarification can be done; you mention backwards
  compatibility, but I think "interoperability" more broadly is even
  more useful.


Sec. 2:

* "rational" seems like a typo for "rationale".

* "Prior to this, domain referred to principally an administrative
  domain, such as the initial organizations involved in networks at
  the time." Conceptually, this is probably where the idea comes from
  that there's necessarily some connection between a domain name and a
  human-accessible "meaning" in addition to a "value" that can be
  reliably looked up and compared by machines.

* "Noticeably absent is a terminating dot or any mention or
  representation of a root." To me, the mention of a tree does seem to
  imply a root, though, as a matter of definition of the type of graph
  we're talking about....yes?


Sec. 3.1:

* "The DNS protocol place size restrictions..." should be "places"

* "The DNS creates the notion that names are assigned by an authority
  per zone." Doesn't it also create the notion of "zone" as distinct
  from "domain" also? or is the distinction referred to earlier? It
  doesn't seem to me that it would be meaningful without the notion of
  explicitly hierarchical delegation of authority, which we didn't
  have in the hosts.txt file-- we needed the DNS protocol for
  recognizing the distribution of authority in the traversal of the
  tree and the resolution of names.

* "In sum, the treatment of ASCII (and only ASCII) cases as equivalent
  is a distortion of the Domain Name hierarchy." 

  Two comments on this paragraph: did we previously describe the
  Domain Name space explicitly as hierarchical, or as a (graph
  theoretic) tree? I think this point is important, but it makes sense
  to establish the underlying property before noting the violation of it.

  And it took me a couple of times through this sentence before
  realizing "cases" meant "upper/lower" and not examples or items in a
  list, so it might read better as "...ASCII (and only ASCII) upper
  and lower cases..." I think this is important because trying to
  duplicate the decisions about DNS names and case with respect to
  other domain names and other properties has led a lot of people
  astray over a long time-- it's an analogy that keeps being made even
  though it's almost always a bad one. Clarity that it's a specific
  exception to a fundamental property of the namespace could be
  helpful.

* I find myself suspecting there's a meaningful distinction to be made
  between protocols that "interact" with DNS and protocols that
  actually "interoperate" with it. :-)


Sec. 3.2:

* If you change "specifically" to "explicitly" in the previous
  sentence, "The reference is explicit." at the end of paragraph 2 is
  redundant.


Sec. 3.3:

* The description "....a way for client software to know how to
  resolve a name, that is, convert a name into a network address."
  seems like a pretty limited assumption about what happens in name
  resolution, even in URIs. Maybe "....convert a name into its
  intended value" is more generic?


Sec. 3.6:

* Does it make sense to say a few more words about what constitutes
  "undesirable outcomes"? Is IDNA the first appearance of such a
  convention with any dependence or basis on human factors issues such
  as "confusability" or identification of "variant"? There's a notion
  with Unicode and IDNA of ambiguous or indeterminate
  transformation/normalization that makes comparison unreliable in
  some situations, and identifiers based on some codepoints
  potentially unstable. But RFC 4290 seems to go considerably further
  in establishing the idea that some constraints about formation and
  delegation of valid strings in the DNS namespace should depend on
  human ability to evaluate them, not only whether they can be
  unambiguously compared and manipulated by code.


Sec. 3.7:

* Is it worth noting that the resolution protocol for Tor names is
  also different to DNS, and that querying the global DNS for a
  ".onion" name is, within the Tor protocol, something that's not
  supposed to happen? i.e. it's intrinsically an error to query the
  DNS for such names at all.


Sec. 3.9:

* Reference to what's punycode alongside the pointer to the
  explanation of why it's not used in mDNS?


Sec. 5:

* Not sure why Lyman's candidate definition was removed; as a way of
  tying the whole discussion together into a generally usable whole, I
  thought it was useful. Since there's no thought of making this
  document normative, I would think it could provide, at worst, a
  useful guideline to protocol and software developers.

  Or do too many protocols use "domain names" that don't follow
  Lyman's definition?