On 2/4/2010 12:02 PM, Jeffrey Hutzelman wrote:
--On Wednesday, February 03, 2010 03:27:01 PM -0800 Russ Allbery
SM <sm(_at_)resistor(_dot_)net> writes:
At 17:03 01-02-10, Russ Allbery wrote:
Ah, thank you. Changed to SHOULD on the assumption that the
language in RFC 1034 was intended to have roughly the same meaning.
"SHOULD" as a requirement first appeared in RFC 1122. It does not
necessarily apply to RFCs published before RFC 2119.
I guess I'm not clear on what you think the correct fix is. I'm
to use a lowercase "should" in a document that explicitly references RFC
2119, since then it's ambiguous what that is supposed to mean in
a standard requirement.
Agree. I think we want to elevate this to SHOULD in this case, even
if the original 1034 requirement was not that strong. Clients failing
to operate this way presents real operational problems for AFS cell
administrators. I would suggest a slight rewording, so that the
present text cannot be read to imply that 1034 says "SHOULD" in the
2119 sense, when in fact it is somewhat more ambiguous.
AFS clients MAY remember which targets are inaccessible by that
client and ignore those targets when determining which server to
contact first. As is common practice, clients which do this SHOULD
have a mechanism to retry targets which were previously inaccessible
and reconsider them according to their priority and weight if they
become accessible again.
Description: S/MIME Cryptographic Signature
Ietf mailing list