ISE write-up for: draft-thomas-namecollisions-workshop-report-05
Abstract:
"This document provides context and a report of a workshop on Root
Causes and Mitigation of Name Collisions, which took place in London,
United Kindgdom, on March 8 to 10, 2014. The main goal of the
workshop was to foster a discussion on the causes and potential
mitigations of domain name collisions. This report provides a small
amount of background and context, then provides a summary of the
workshop's discussions."
This draft has no IANA Considerations. It does not make any
statements about how IANA should behave, it simply documents the
meeting referred to in its abstract.
It was reviewed for me by Olaf Kolkman and Edward Lewis (their reviews are
appended below); its authors have made the changes discussed between them.
- - - - - - -
Olaf Kolkman's review:
Attached is a word document with a few comments, these can be shared
with the author. For some reason the introduction rubbed me the
most. I hope that the tweaks help correctness and readability.
Below are some additional comments that are in the category of
comments for the ISE.
* _"This document is primarily a report on the March 2014 workshop that
set out to examine the causes and mitigation of such name collisions
and their associated risks. It is a companion to the workshop
proceedings at [WPNC], and it also provides some additional
background and context."_
Perhaps some words could be added around the 'consensus' behind the
report. But only if you are concerned with that. I have reviewed some
of this text some time ago. I would say it is a reasonable report but
I would be hesitant to have a position around whether it represent
the consensus of the workshop (or not).
Edward Lewis's review:
I read the draft and have some comments.
I'll start with comments on sections 2 to the end. I usually find, as
was the case here, that the introductions to such reports are hard to
write and thus read, once past the introduction the sailing is
smoother.
Post Introduction:
1. Stylistically, using citation "hooks" to refer to documents makes
reading very hard. I would list the titles at least. I would prefer
if the paper explicitly used the agenda as an outline, one subsection
per paper considered, and list any results in the paper. As this
document is written, it's an advertisement to go get the paper (not a
bad idea) that is written so "choppily" (constantly having to refer to
the references section) that any hope of a narrative is lost.
2. Typo "lack or accessible"
Unsurprisingly, there's not much to question when commenting on a
report of a workshop (which I didn't attend ;)), past any general
readability issues.
But for the Introduction:
My bias here is that during the (longer-term) build up to the Workshop
I was working for an organization preparing bids for the 2012 new gTLD
program. We were part of the group that recognized that ICANN had
delayed addressing this (based on recommendations cited in the draft
at hand) and saw the efforts to make name collisions an issue in
2012-2013 as a delaying tactic. I.e., I wasn't an ICANN person at the
time, although by March 2013 I was a full-time independent contractor
to ICANN (staff by May).
First the introduction is very hard to read. I would fix it by
sequencing it on time, evolving the story over time. The narrative
jumps time perspectives, from current to past. The paragraph that
begins "In order to help ensure" is one that took a long time to
parse.
Second, there is confusion over ICANN and the IANA Functions Operator.
For instance, ICANN does not administer or delegate county code TLDs,
it would be fairer to say that the ccTLDs hold ICANN in disregard.
The IANA Functions operator manages delegations from the root zone,
including to ccTLDs, according to long standing policies. I would
recommend that time be spent cleaning this up, as I see a pervasive
misunderstanding of the IANA, ICANN, Root Zone Management process
within the IETF community chatter (see the discussion around the
Special Use Domain Names registry as an example).
Third I think that the introduction shortchanges the dynamic of the
non-IETF/ICANN world participants in the use of names. Commercial
vendors have shipped products and documentation (and training
materials) that have led to the operational issues we see, if this
were better described then the reader would walk away with a much
better understanding. What one senses as "abuse" of names is subject
to one's perspectives.
Fourth, ripping this from my raw notes (the line numbers are what I
guessed from a screen scrape of the draft):
148 ## of ownership and autonomy. The Internet's global DNS is an
exemplary
149 ## system in which name space governance is critical to ensure
name
150 ## uniqueness.
The previous sentence hits me very deeply. I disagree based on the
qualification of DNS as the "Internet's global". If the sentence is
true, there may be a misunderstanding of the DNS system rooted at IANA
versus the DNS protocol, which underlies the IAB's Internet Names and
Identifiers Program.
Name-collisions, in the context of this workshop is concerned with the
expansion of of the Internet's global DNS in ways that unpredictably
run head on with other uses of domain names. Name space governance is
needed to mitigate the unintended consequences, proper governance,
that is. That isn't to "ensure" uniqueness, rather to soften the
blows when names are no longer unique.
Sixth, the document should include more references for definitions,
like "Negative Caching of DNS Queries (DNS NCACHE)" as the definition
of NXDOMAIN.
Seventh, there are two cases of an extra whitespace at the start of a
line suggesting that a paragraph break seems to be missing. (127 and
179 by "my line count".)
Other nits:
Typos "formationof" needs a whitespace. And "IETFcommunity" too.
Other comments:
Referring to a link to RFC 6761 - How "the goal" is defined by the
reference given is a mystery (I mean, no linkage given, not a comment
on the Special Use Domain Names registry itself).
187 ## operators or administrators who elected to use the same name
space
188 ## internally may face potential "name collision" problems.
"the same name space" isn't accurate. The name space is a broad term, the
collisions will happen for those operating or administering names that
were configured without formal delegation once a formal delegation is made
for the name - to some other entity.
- - - - -