ietf
[Top] [All Lists]

Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP

2010-03-18 11:24:57
At 9:25 AM -0400 3/18/10, Andrew Sullivan wrote:
The DNSSEC algorithm registry has no slot in it to indicate the
support level appropriate to each algorithm.

True. What does "support level" apply to? RFC 4034? RFCs {4034 | others}? 
DNSSEC-the-protocol? The IANA registry itself? Without a precise definition of 
the desired target for the conformance requirements, this draft is harmful 
because it dilutes the conformance requirement mechanisms we currently have.

An RFC can list conformance requirements for that RFC. This is already common.

A group of RFCs can list conformance requirements, but the linkage between the 
RFCs make this trickier.

- If RFC A, B, and C are issued simultaneously and each cross-references each 
other as normative references, RFC A can list the conformance requirements and 
everyone understands that those requirements apply to {A | B | C}.

- If RFC D has conformance requirements and RFC E updates RFC D but doesn't 
change the conformance requirements of D, then everyone understands that the 
conformance requirements in D apply to E.

- If RFC F has conformance requirements and RFC G updates RFC F and changes the 
conformance requirements of F, then the new conformance requirements only apply 
to RFC G, not F. This is where implementers often start to lose it. The 
misunderstanding often gets worse if G updates F, but F was part of a grouping 
of cross-linked RFCs.

As John Klensin made clear, the IETF has tried and failed miserably to allow 
the definition of Foo-The-Protocol in a way that can have clear conformance 
requirements that can later be updated. Just saying "newtrk" to some IETF 
regulars will cause them to swear reflexively.

Trying to say that an implementation conforms to a particular IANA registry is 
a new concept that is so badly under-defined in the draft that I assume that it 
was not intended even though it was strongly implied.

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?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>