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