[AFS3-std] Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard

[Jeffrey Hutzelman]

--On Thursday, February 04, 2010 01:59:36 PM -0500 Jeffrey Altman 
<jaltman@secure-endpoints.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@stanford.edu> wrote:
>>
>>> SM <sm@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.
>>
>> -- 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.