I would like to add my support here to Dave Crocker's very thoughtful and
IMHO accurate description of this revised draft. I share his views that the
substantive criticisms have not been addressed.
What exactly is the harm that this draft proposes to prevent? I can
certainly understand the natural reluctance to continue to pile on to the
DNS various data attributes but its should be clear that that this cat has
been out of the bag for some time.
Clearly we do not want the DNS to be used for search like functions where
there may be a indeterminate response but the examples cited do not address
those issues. I am baffled by the ongoing criticism RFC 6116 and the desire
of some members of the community to extend 6116 to values that may not
necessarily be defined as a URI. ENUM works and works quite well in both
e164.arpa and in private instantiations.
Frankly I think this draft needs to be completely withdrawn.
If there are issues with new uses of the DNS, DNSEXT or DNSOPS are fully
chartered to provide community review and do not need any "fuzzy" guidance
on what is and is not acceptable. This entire draft could beeasily
simplified byt a one sentence statement.
"If you need to do database look ups in the future we would prefer that you
think of using protocols other than the DNS."
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Dave
CROCKER
Sent: Thursday, July 21, 2011 6:41 AM
To: IETF Discussion
Subject: Review of: draft-ietf-iab-draft-iab-dns-applications-02
This is a summary of a followup review of the draft, after the one noted
in
Ticket #35 of the trac wiki for this draft:
<http://trac.tools.ietf.org/group/iab/trac/ticket/35>
The complete version of this second review is at:
<http://trac.tools.ietf.org/group/iab/trac/ticket/35#comment:2>
Summary:
The latest version of the draft contains many substantial changes.
However it continues to have basic problems with direction, scope, detail,
writing, and with basic confusion about architecture.
The draft maintains its claim of being a general considerations
discussion when, in fact, it continues to focus on fear of inappropriate
proposals. It continues to invoke examples of inappropriate proposals
that lack constituency or even currency.
In spite of language claiming to distinguish new /uses/ of the DNS
from /changes/ to the DNS, the draft continues to confuse the two. The
problem appears to be a difficulty distinguishing architectural layers.
This is like saying that TCP changes IP or that HTTP changes TCP. Hence,
for example, DDDS is a layer /above/ the DNS. The only two interesting
questions about a client layer's use of a provider layer -- such as DDDS's
use of DNS -- is whether the functional match is acceptable and whether
it's performance demands cause problems. When focused on one layer, any
further discussion of the other likely to confuse things significantly, as
demonstrated in the draft.
The paper continues to make broad criticisms that lack foundation and
sometimes even lack citation.
Some of the statements and logic sequences were entirely opaque to me.
I could not decipher what they meant. In some cases the apparent meaning
was factually incorrect or confused.
From all of this, I suspect that the only way to make useful progress
is to start over, and to begin with a much, much more clear and concrete
statement of the goal for the draft and then a very diligent effort to
organize the paper's sequence and carefully document its assertions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf