![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
At 15:27 03-02-10, Russ Allbery wrote:
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.
If I was quoting RFC 1034, I would use the same text. That is to avoid having different interpretations if people doing "copy and paste" editing reuse the text from the draft.
In the first sentence of that paragraph, you have clearly explained that the SRV record information is no longer valid after the time-to-live. You already have a requirement in that paragraph (information derived from the DNS SRV RR MUST be discarded).
Quoting some text from RFC 2181: "In some sections it may seem that a specification is worded mildly, and hence some may infer that the specification is optional. That is not correct. Anywhere that this memo suggests that some action should be carried out, or must be carried out, or that some behaviour is acceptable, or not, that is to be considered as a fundamental aspect of this specification, regardless of the specific words used. If some behaviour or action is truly optional, that will be clearly specified by the text."If what the reader is supposed to do and why it should be done is clearly explained, there is no ambiguity. We can only hope that common sense will prevail.
At 09:02 04-02-10, Jeffrey Hutzelman wrote:
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.
If it can cause operational problems, then the present text should be reworded. I'll reuse text provided by Russ:
DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid [RFC1034]. DNS RRs SHOULD be discarded after their TTL, and the DNS query repeated. This applies to DNS SRV RRs for AFS as to any other DNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired.I moved the RFC 1034 reference to the first sentence in that paragraph. I removed the "As specified in" to avoid any inference that the "should" in RFC 1034 has been elevated to a "SHOULD".
At 10:59 04-02-10, Jeffrey Altman wrote:
How about? AFS clients MAY remember which targets are inaccessible by that client and ignore those targets when determining which server to
The paragraph being discussed is between lines 216 and 222 in draft-allbery-afs-srv-records-03.
Regards, -sm
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.