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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]