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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf