On 26 Feb 2015, at 00:14, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
(1) Integrity of the standards process.
For many years, it was a key IETF principle that standardization
of a particular technology meant that the community had been
able to review all of the details, make changes where needed,
and then reach rough consensus on the result. The notion of
registering an RRTYPE via Expert Review and then turning around
and asking that it be standardized while claiming that details
(or even design principles) cannot be changed because it is
already registered and in use represents a fundamental departure
from and threat to our historical standardization model. No
malice is implied here, just a bad sequence of steps. I don't
know that it makes a lot of difference how this particular spec
is classified, but, noting that the same situation could apply
to a number of other specifications where registration is by
expert review (Media Types come to mind as do URIs and, if
2141bis is approved in more or less its current form, URNs), it
seems to me that the IETF needs to address this issue, perhaps
confining specifications for already registered names to
Informational or Experimental categories and figuring out an
alternative to expert review for specs that people will want on
the standards track.
There is no requirement to use expert review. The full blown rfc
process is still available. If you use expert review however the
format of the record is fixed when the review is done. [ For the
record the format of the record changed which was annoying for those
of us that wrote explict code to handle the type. The reference
for the type will need to be updated if it hasn't been done. ]
I think there are a number of things we have problems with in the IETF. Like
cross-area-review and because of this design. Each area look at things from
their perspective and hold hard to their ideas on the future of the world.
In this specific case, sure, like many other definitions by IETF it was not
optimal when the review happened, but maybe it is wrong to have the later
published RFC on standards track as it seems to end up? Maybe it should be
"just" informational (if that matters).
Regarding the change that Mark point out in this case, the clarification that
was made from an earlier draft to what we now have have are I claim not
incompatible with what is in the application for an RRType that was applied
for. The difference is that we now clarify that the URI is "just bytes" to the
end of the RDATA field. It is not an (as defined in DNS) text string which has
limited length. I.e. we all remember a TXT RRType can have multiple text
strings in the RDATA field.
This clarification was made in cooperation and in coordination with people that
implement URI (which was when this was discovered).
At least that is what I think you do talk about Mark?
Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail