At 11:10 AM +1300 1/16/08, Brian E Carpenter wrote:
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.
Yes, that sounds reasonable. I'll prepare an appendix with some discussion on this.
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.
That section of RFC 2026 talks about Applicability Statements. Does that really apply here? I think that the new terms only apply to TSs, not ASs.
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).
Good point, added.
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).
Good catch. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf