--On Tuesday, December 22, 2009 00:22 -0500 Olafur Gudmundsson
<ogud(_at_)ogud(_dot_)com> wrote:
Correction the message should have been:
http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html
Olafur
At 00:18 22/12/2009, Olafur Gudmundsson wrote:
John, SM
do the changes that Ted Hardie asked for address your
concern(s)? see:
http://www.ietf.org/mail-archive/web/ietf/current/msg59759.ht
ml
Olafur,
It seems to me that Ted's message asks for more clarity about
what is being specified, actual review by email-related groups
of email-related records and their implications, and so on.
Certainly I agree with those requests and concerns. Your
response is fine, except I have no idea what is actually going
to get done, and what those reviews will produce, until I see
the results. And those issues are sweeping enough that I really
wish the Last Call would be terminated and restarted only when
those reviews, and a document that reflects them, is in place.
From that point of view, I'm objecting less to the content of
this proposal (as far as it goes), but to the fact that the
ducks don't seem to be lined up prior to its going out to IETF
Last Call. The comments below are more substantive.
All we want sink-arpa to do is to create a domain name with
known characteristics and create a mechanism to define other
such domain names that may have other characteristics for
various applications.
But that is, from my perspective, a large part of the problem.
If SINK.ARPA (or its non-existence) is intended to support
various functions, those function should be enumerated and be
well-defined. By contrast, this document does some handwaving
and includes two specific examples, at least one of which is a
little problematic (and that has not been reviewed by the
relevant community).
I see two other issues that are basically corollaries:
(1) In practice, there are many parts of the Internet today
where various diversion strategies for failed DNS lookups result
in a situation in which NXDOMAIN may not get back to the party
issuing the query, at least absent some special case work. It
is not clear whether that special case work is harmonious with
the intent of this proposal; part of your response to Ted
suggests that it is not. Perhaps DNSSEC will solve that
problem. Perhaps the desire to commercially exploit those
diversions will inhibit the deployment of DNSSEC. But it seems
to me that the document should at least contain an analysis of
those issues because they may constitute failure cases.
(2) Whether names are allocated or permanently reserved, I think
there are considerable advantages to keeping the logical second
level of .ARPA as small as reasonably possible -- the minimum
number of names that are operationally necessary and no more.
From that perspective, creating an IANA registry into which one
can easily add names that are logically second-level domains in
.ARPA (even if they are never allocated) would be a mistake. If
you were confident that exactly one such name were going to be
necessary, then maybe. But, if you anticipate more such names,
as seems to be the case from the notion of setting up a
registry, then it seems to me that all of the traditional
arguments for hierarchy in the DNS apply and this should be set
up with the expectation, not of
sink.arpa.
sunk.arpa.
drowned.arpa.
bitbucket.arpa.
seriously-fubar.arpa.
etc., but as
sink.bogus.arpa.
sunk.bogus.arpa.
drowned.bogus.arpa.
bitbucket.bogus.arpa.
seriously-fubar.bogus.arpa.
and so on. As with the proposal in the document, the specific
names are not important; the structure is.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf