--On Monday, May 20, 2013 09:55 -0700 joel jaeggli
<joelja(_at_)bogus(_dot_)com> wrote:
I don't know who the current expert is and, for the moment, am
glad I don't and don't intend to check. I believe there is
broad consensus in the community that having something as
significant as an RRTYPE documented in the RFC Series is a
good idea.
IETF consensus tends to indicate that is is better to assign
new RR-types then it is to keep having developers jam these
usages into text RRs.
I certainly agree with that. If I had my druthers, the IETF
would have loosened up on registrations and issued a strong
statement discouraging the use of text RRs for anything other
than what I believe was their original purpose -- unstructured
textual comments to be read by humans. So no disagreement
there. But even in the pre-1999 IANA days and with registries
that were almost purely FCFS, the then-universal expert reviewer
felt it was reasonable to deal with an application for two code
points by saying something equivalent to "hey, can't you use one
and a different data structure?". It is, IMO, an obvious
question and, other issues aside, I think the answer should be
explained in the document. How strong "should" is depends on
another consideration; see below.
Certainly leaving the reference pointing, long-term, to
an I-D would not be a good idea (and would violate several
other principles).
an ISE submission for documentary purposes would minimal
impediment and documentary value would be preserved an rr-type
assignement might well point at an external resource.
Yes. And? I didn't say "no external reference", I said "no
permanent reference to an I-D". Remember that "not an archival
series", "reference only as work in progress", etc., stuff?
Again, see below.
However, if
(i) the expert review consists largely of making sure
that the template contains the right information and the
ducks are not obviously out of line rather than a
design/architectural review with at least meaningful
potential for community review of the request, and
(ii) the response to a design/architectural concern
raised during IETF LC is essentially "too late, code
points already allocated", and
IETF LC should be, "can we live with this?" The document has
been discussed in dnsext and reviews were requested, I was
prevailed on to take it on as that WG is supposed to be
shutting down.
See below.
(iii) "Proposed Standard" still does not imply
"recommended" and the alternative to approving the I-D
for that category is non-publication,
...
So, I don't have a problem philosophically or otherwise with
the fact that there my be a better solution out there. It
takes somebody to do that work. The can obviously get an
rr-type for that application.
...
Somewhat informed by your note and the other responses to my
original one, let me clarify what I'm suggesting...
(1) As indicated above, I think that an easy application and
registration process is A Good Thing for RRTYPEs (and lots of
other things). Unless there is some substantial reason to not
do so, I think that such registrations should be bound to
sufficient information to make interoperability easy or at least
feasible. In the general case, I don't think it makes any
difference where that information is recorded as long as the
document location or maintenance arrangements are sufficiently
stable to create a plausible expectation of long-term
accessibility of the description. I note that the latter has
been an IANA requirement since before there was an IETF and that
occasional exceptions have been made for almost that long.
(2) I think publication of descriptions of RRTYPE values (and
other parameters) in the RFC Series is generally A Good Thing
and that it should be encouraged. If that results in better
quality documentation or documentation that is easier to
interpret in ways that increase interoperability, that is great.
(3) However, if someone wants both a code point (in this case,
RRTYPE) or two and an IETF Standards Track document, they should
expect to conform to IETF norms about standards track
specifications. I think those norms include the expectation of
a meaningful IETF Last Call that could, e.g., question design
decisions, expect substantive responses, and expect changes if
the consensus leads that way. The situation with a WG document
being processed inside a WG and with an individual submission
for Standards Track ought to be the same: design decisions
belong to the WG or IETF, not the authors. A registration
procedure should not be able to be used to create a back door
and preempt that principle, so the would-be registrants can use
the expert process to register whatever they would like but, in
doing so, they should accept that, if they want to publish in
the RFC Series, the result will be Informational. Or, if they
want whatever value that IETF Standardization adds, they need to
make a proposal to the IETF and let it be reviewed, and possibly
changed, by the process. If they pick the latter course, it
will usually be preferable to defer registering until the IETF
reaches consensus but, if that is not feasible, they need to be
prepared for the IETF to agree on something else, expect to be
asked to reflect that in their document, register the
agreed-upon solution, and then deprecate the earlier
registrations (possibly leaving their documentation in an
appendix to the Standards Track RFC).
It seems to me that, if someone can register something, ask for
Standards Track status, and then reject requests to discuss
changes on the basis that the registration has already occurred
and expect the document to be standardized anyway, the standards
process is headed toward fairly difficult territory.
john
p.s. Thanks to you and Barry for the explanation of the
shepherd/ tracker problem.