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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]