(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.
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.
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).
best,
john
< where you goin' with that gun in your hand? >
i am not at all sanguine about the issues raised in the in sec
cons. i accept that NTRE038D may have asked that these be in
the dns, but seems to me that it is ill advised and some other
means to meet their actual needs might be found. e.g. what's
the matter with logs?