![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.edu> wrote:SM <sm at resistor.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. -- JeffHow 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.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.