At 06:25 18-03-10, Andrew Sullivan wrote:
I understand this objection, and I have some sympathy with it. At the
same time, there is a serious problem with at least one registry that
the draft aims to fix. I think that problem is worth taking on.
According to the draft, the problem is about how "to indicate
emerging and retiring algorithms". I agree that the problem is worth
taking. As the registries are used throughout the different areas,
it would have been helpful if the proposal had more exposure. It
would have been good if the socializing, to use Olafur's words, was
done before the Last Call.
The DNSSEC algorithm registry has no slot in it to indicate the
support level appropriate to each algorithm. As we saw in recent
debates, there is considerable feeling among IETF participants that
some algorithms need to be supported by everybody, and some are likely
only to be required in particular situations.
I gather that the above refers to draft-ietf-dnsext-dnssec-registry-fixes-02.
Today, if you want to find out whether an algorithm is mandatory to
implement, or optional to implement, you have to go and read through
every RFC for every algorithm, as well as some other RFCs that don't
actually specify an algorithm but instead specify the protocol. This
is a trivial task for someone familiar with the ways of the IETF. For
someone unfamiliar with those ways, it is a convoluted mess that is
hard to navigate. Not every programmer is as diligent as we might
like, and so if we put this sort of barrier in the way of proper
implementation, what we'll get is lousy interoperability.
Currently, IANA manages the namespace. What we have, roughly, is a
list of assignments and a reference, for example a RFC, to document
the action. The proposed fix, to save the programmers' time, is have
a one-stop shop which lists the required algorithms, the ones that
will be obsoleted and the ones planned for use in future.
On a tangent, it can be argued that the fix is about creating
different classes of "Proposed Standard" RFCs.
To borrow words from Paul Hoffman, the "IETF has never had a concept
of compliance to an IANA registry, which is a good thing" (I cannot
provide a reference as the archive for this mailing list only lists
messages up to March 15). As Brian Carpenter mentioned, "IANA itself
cannot add normative requirements - only an IETF standards action can
do that". John Klensin mentioned that putting critical information
in an IANA registry is probably not a good idea. One of the effects
of this proposal is that the programmer will be complying with the
IANA registry to cherry pick which protocol or algorithm to implement.
Moreover, it would be awfully nice if we captured somewhere, "This
algorithm is still required, but it's on its way out," and, "That
algorithm isn't required yet, but real soon now it will be." That
way, when a developer of code is trying to decide what to do, there is
a useful guide not only of what the state of affairs is today, but
what it likely will be in six months, one year, &c. (I'm aware of the
amusement likely to be caused by the idea that DNSEXT could actually
plan what work will really be done in the next 6-12 months.)
That would be STD [1] except for the "which algorithm is on the way
out or which algorithm will be in on the next iteration". The begs
the question as to why this new mechanism would be successful when
the existing mechanism is a failure.
At 07:59 18-03-10, Edward Lewis wrote:
A registry is a reference service. It is best when consulted for information
that can be used to make other judgements. As with just about any other
coordination function, the more (problem) domain intelligence that is built
in, the less flexible the function will be.
Agreed.
The problem with adding compliance requirements to the IANA registries is
that this assumes all implementations are general purpose applications. In
as much as there is no "protocol police" there is no necessity to have
every process listening on port 53 (DNS) to implement the full spectrum
of the protocol's features.
The vendor can claim compliance. It is not for the IETF to say what
specifications to comply with. However, the community can document
what it agrees to be common practice.
At 09:24 18-03-10, Paul Hoffman wrote:
If the real reason for this draft is to set conformance levels for
DNSSEC (something that I strongly support), then it should be a
one-page RFC that says "This document defines DNSSEC as these RFCs,
and implementations MUST support these elements of that IANA
registry". Then, someone can conform or not conform to that very
concise RFC. As the conformance requirements change, the original
RFC can be obsoleted by new ones. That's how the IETF has always
done it; what is the problem with doing it here?
If that is the problem this proposal is attempting to solve, write
the I-D as mentioned above. Such a proposal should face less
resistance than trying to come up with a generalized approach.
Regards,
-sm
1. http://www.rfc-editor.org/categories/rfc-standard.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf