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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf