At 1:10 PM +1300 3/18/10, Brian E Carpenter wrote:
Ah, yes, Paul is quite correct. My implicit assumption was
that such keywords would be added to an IANA registry only
in as far as they echo IETF standards track documents (including
the deprecation or obsolescence of such documents). Of course,
IANA itself cannot add normative requirements - only an IETF
standards action can do that.
But even then, there are problems. Most IANA registries can apply to more than
one RFC. If Registry A is created by RFC X, and RFC X is updated by RFC Y,
everyone understands that the registry applies to both RFC X and RFC Y. But if
Y introduces different "mandatoryness", what does it mean for compliance to RFC
X? Does one clone Registry A into Ax and Ay?
The basic idea of this draft puts the compliance wording in IANA registries
instead of in the RFCs themselves. This is fine for single-RFC registries, but
falls apart completely for registries that apply to more than one. There is no
need for this: let RFCs continue to define compliance to the RFC.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf