--On Tuesday, May 21, 2013 15:42 -0400 Olafur Gudmundsson
<ogud(_at_)ogud(_dot_)com> wrote:
...
John,
There are basically 3 different kinds of DNS RRtypes,
- types that affect the behavior of the DNS protocol and are
cached by resolvers,
- types that have DATA and are cached by resolvers
- meta Types that may affect processing but are not cached.
DNSEXT in its wisdom has deemed the second group to be
"harmless" as far as DNS is concerned and getting code to
store data in DNS is a good thing, thus it is easy to get it.
Getting code for the other classes requires IETF standards
action.
Seems perfectly reasonable
Documents that describe the DATA types use are encouraged to
be published as Informational or some other stable reference.
Reasonable too. My problem here, which I hope was clear from
the note from which you quoted, is that a request/document in
the second category was proposed for Standards Track and then
that comments that would be entirely appropriate for a Last Call
on a Standards Track document were essentially rejected on the
grounds that they would require changes to already-registered
RRTYPEs.
These are not new issues and we have historically dealt with
them in a number of ways that don't require moving away from
liberal allocation policies and toward "the IETF is in charge
of the Internet and has to approve everything". For example,
we have decided that media types don't have to be standardized
although certain types of names do. People then get to choose
between easy and quick registration and standardization, but
don't get to use the first to leverage the second. One could
argue that the pre-IETF (and very early) division between
"system" and "user" port numbers reflects the same sort of
distinction between a high standard for justification and
documentation and much lower ones.
As I explained DNS RRtype allocation has this separation.
But the request for publication in the Standards Track violates
it.
It is possible (although I'm not convinced) that this
discussion should suggest some tuning of the allocation model
for RRTYPEs. Probably that model is ok and we just need to
figure out clearer ways to say "if you want standards track,
don't get an allocation first and try to use that as
justification because you will get a real Last Call anyway
and everyone will end up a little irritated". Or something
else may be appropriate. But it seems to me that, as soon as
one wants to say "all protocol parameters or other data
values should be standardized" then allocation models based
on expert review are inappropriate. For the RRTYPE case,
that issue should, IMO, have been pushed with the relevant WG
when the decision to allow expert review was made (and,
again, IMO, that cure would be worse than the disease because
it would indirectly drive more folks toward overloading of
TXT and other existing types).
If the expert thinks an application crosses from DATA space to
Control space he is expected to reject the application and
ask for clarification.
We are agreed that isn't an issue here.
So far nothing has shown up that crosses this boundary, so
there is no problem. I will go as far as saying why should
there be higher bar for getting a DNS RRTYPE than MIME media
type ?
With the understanding that I don't think it has anything to do
with this situation, one could justify a different (and maybe
higher) bar in two ways. First, the media type names are
structured so that, a few historical exceptions aside, one can
tell what category they are in by looking at the names. To get
that effect with RRTYPEs, one would have to take the categories
you spell out about and create (as a silly example) type names
starting in "1" for the first category, "2" for the second, and
so on, or otherwise lexically distinguish the second category
from the other two. Second, the potential code space for media
types may be a tad larger than the potential RRTYPE code space.
But, again, I think the question is irrelevant here -- I've not
advocating changing the allocation rules, only keeping the
relationship between already-allocated RRTYPEs and the Standards
Track into the categories you have described above.
--On Tuesday, May 21, 2013 15:24 -0400 Joe Abley
<jabley(_at_)hopcount(_dot_)ca> wrote:
Code-points in the RRType registry are assigned by expert
review (not simply by "filling out a template" as someone
suggested earlier).
I was the one who said "filling out a template" and that
reflects a bad attitude toward many expert reviews. That
attitude and what underlies it has nothing to do with this
situation.
If the suggestion is that the standards
track is not available for any work that involves a code point
that was assigned early, then I wonder what process is
imagined for any future DNS work which aims at the standards
track.
Presumably the same mechanism that has now been used for other
registrations that are normally expert review (or less) but that
interact with standards-track work: one develops a
specification normally, puts it through the standards track, and
only then asks IANA to register the relevant parameters (and
either asks or directs the expert to sign off). If the existing
RRTYPE registration rules prohibit that, I would suggest they
are badly broken but I can't imagine how they could be written
to specify such a prohibition.
One could argue that all of our "expert review" procedures
should say "expert review except where the standards track is
used for other reasons" but the application of good sense says
that the expert should either consider the IETF Standards Track
review adequate and sign off or should be screaming loudly about
the deficiencies during Last Call.
Once more, the only important thing I'm objecting to here is
registering the RRTYPEs using the expert method, then asking for
Standards Track publication, then responding to Last Call
comments by saying something equivalent to "you don't get to
discuss that because these types are already registered". I
think one can either say "standards track is not needed, publish
the description of the types as Informational" or that there is
an obligation on whomever is proposing standards track to figure
out how to make the review process work properly and without the
existing registrations being considered as a constraint. I
don't think that is very complex or unreasonable. YMMD.
john