--On Thursday, February 04, 2010 01:59:36 PM -0500 Jeffrey Altman
<jaltman(_at_)secure-endpoints(_dot_)com> wrote:
On 2/4/2010 12:02 PM, Jeffrey Hutzelman wrote:
--On Wednesday, February 03, 2010 03:27:01 PM -0800 Russ Allbery
<rra(_at_)stanford(_dot_)edu> wrote:
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
(pre-2119)
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
hesitant
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
terms of
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.
-- Jeff
How about?
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.
That's not the text we're talking about.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf