The careful approach needed for phasing crypto algorithms
in and out may justify such terminology. However, I think
there is experience that careless use, in particular of
SHOULD+, which has crept into some non-IETF documents such
as procurement specifications, has great potential for
confusion. What is a vendor who decides not to implement
a SHOULD supposed to do about a SHOULD+? If we really want
to make these terms available to any specification writer,
I'd want to see more explanatory text of when they're
appropriate and when they're inappropriate, and how
an implementor should interpret them.
The concept supplements not only RFC 2119 but also the
discussion of "requirement levels" in RFC 2026 section 3.3.
I think that should be mentioned.
We also need to know how they are to be interpreted
when evaluating a PS for promotion to DS. (Probably there
is no difference from the regular terms, but it needs
to be stated).
Another thing that's missing is the additional
boilerplate need in order to cite these terms (i.e.
an updated version of the boilerplate specified
in RFC 2119).
Brian
On 2008-01-16 08:23, Paul Hoffman wrote:
At 1:43 PM -0500 1/15/08, John C Klensin wrote:
Translation: this seems like an interesting idea, but the
concepts are, IMO, probably much better expressed in nuanced
text rather than in cute codes.
This document does not prohibit, or even suggest against, individual
documents coming up with their own terms, nuanced or not.
A different version of the
same thinking would suggest that any document needing these
extended keywords is not ready for standardization and should be
published as Experimental and left there until the community
makes up its collective mind.
It seems that you didn't read the whole document; RFC 4307 already uses
these terms. My experience with talking to IKEv2 implementers (mostly
OEMs at this point) is that they understood exactly what was meant and
were able to act accordingly when choosing what to put in their
implementations.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf