Hi. I'm going to comment very sparsely on responses to this
draft, especially those that slide off into issues that seem
basically irrelevant to the registry and the motivation for its
creation. My primary reason is that I don't want to burden the
IETF list with a back-and-forth exchange, particularly about
religious matters. The comments below are as much to clarify
that plan as they are to response to the particular comments in
Phillip's note.
--On Friday, August 30, 2013 10:16 -0400 Phillip Hallam-Baker
<hallam(_at_)gmail(_dot_)com> wrote:
RFC 5507 does indeed say that but it is an IAB document, not
an IETF consensus document and it is wrong.
Yes. it is an IAB document. And, yes, one of the coauthors of
this draft is a coauthor of 5507 and presumably doesn't share
your opinion of its wrongness.
But that is irrelevant to this particular document. 5507 is
used to set context for discussing the need for the registry and
to establish some terminology. If the Hallam-Baker Theory of
DNS Extensions had been published in the RFC Series, we might
have drawn on it for context and terminology instead. Or not,
but we didn't have the choice. Your description of the motives
of the authors of 5507 is an even better example. Perhaps you
are correct. Perhaps you aren't. But whether you are correct
or not makes absolutely no difference to the actionable content
of this draft.
The "more prefixes" versus "more RRTYPES" versus subtypes versus
pushing some of these ideas into a different CLASS versus
whatever else one can think of are also very interesting... and
have nothing to do with whether this registry should be created
or what belongs in it.
Since you obviously don't like 5507, I would suggest that you
either prepare a constructive critique and see if you can get it
published or, even better, prepare an alternate description of
how things should be handled and see if you can get consensus
for it. This document is not a useful place to attack it
because its main conclusions just don't make any difference to
it. If you have contextual or introductory text that you prefer
wrt justifying or setting up the registry, by all means post it
to the list. If people prefer it to the 5507 text, there is no
reason why it shouldn't go into a future version of the draft.
The consequence of this is that we still don't seem to have a
registry for DNS prefixes, or at least not in the place I
expect it which is
Domain Name System (DNS) Parameters
...
Yes. It it too hard to find. That also has nothing to do with
this particular registry. It is connected to why the I-D
contains a temporary and informative appendix about DNS-related
registries and where one might expect to find them. Our hope is
that the appendix will motivate others (or IANA) to do some work
to organize things differently or otherwise make them easier to
find. But whether action is taken on the appendix or not has
nothing to do with whether this registry is created.
The IANA should be tracking SRV prefix allocations and DNSEXT
seems to have discussed numerous proposals. I have written
some myself. But I can't find evidence of one and we certainly
have not updated SRV etc. to state that the registry should be
used.
The IANA is extremely constrained about what it can do without
some direction from the IETF. The appendix is there to provide
a preliminary pointer to some areas that might need work (at
least as much or more by the IETF as by IANA). If you have
specific things that belong on the list (the working version of
what will become -01 already is corrected to point to the SRV
registry), I'd be happy to add them, with one condition: if we
end up in a discussion of the details of the appendix rather
than the particular proposed registry, the appendix will
disappear. It is a forward pointer to work that probably should
be done, not the work itself.
Fixing TXT is optional, fixing the use of prefixes and having
a proper registry that is first come first served is
essential. Right now we have thousands of undocumented ad-hoc
definitions.
Let me restate that. Some of us believe that it is time to "fix
TXT" or, more specifically, to create a registry that can
accommodate identification of what is being done, whether one
approves of it or not. If other things need fixing too --and I
agree that at least some of them do-- please go to it. If the
appendix is useful in that regard, great. If not, I'm not
particularly attached to it.
Neither the structure and organization of IANA registries
generally nor the future of service discovery have anything to
do with this draft. If you want to discuss them, please start
another thread.
thanks,
john