On May 21, 2013, at 1:32 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
(Changing Subject lines -- this is about a set of general
principles that might affect this document, not about the
document)
--On Tuesday, May 21, 2013 22:23 +0700 Randy Bush
<randy(_at_)psg(_dot_)com> wrote:
joe,
i have read the draft. if published, i would prefer it as a
proposed standard as it does specify protocol data objects.
I would generally have that preference too. But it seems to me
that the combination of
-- RRTYPEs (and a bunch of other protocol data objects
associated with different protocols) are allocated on
expert review
-- The fact that those protocol data objects have
already been allocated is used to preempt IETF
consideration of issues that normally go into Standards
Track documents, including the criteria for Proposed
Standards in 2026.
is fundamentally bad news for reasons that have little to do
with this document or RRTYPEs specifically. If the combination
is allowed, it provides an attack vector on the standards
process itself because someone can get a parameter approved on
the basis of ability to fill out a template and then insist that
the IETF approve and standardize it simply because it is
registered and in use. That would turn allocation of
parameters by expert review (and some related issues connected
to "deployed therefore it is ok" -- watch for another note) into
a rather large back door for standardization that could bypass
the 2026 and other less formal criteria, the IETF's
historically-strong position on change control, and so on.
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.
Documents that describe the DATA types use are encouraged to be published as
Informational or some other stable reference.
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.
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.
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 ?
Olafur