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

From: Russ Allbery <[email-masked]>
Date: Mon, 01 Feb 2010 17:03:23 -0800

SM <[email-masked]> writes:

> In Section 4:

>   "<proto> MUST be "udp" for the current AFS protocol, which uses Rx
>    over UDP."

> It would be better to specify what the current AFS protocol is.

Indeed.  However, there is no existing specification in an easily citable
form.  Some additional references to academic papers will be added to the
initial section of the RFC in the next version.

>   "As specified in [RFC1034], DNS RRs MUST be discarded after their TTL,
>    and the DNS query repeated."

> RFC 1034 actually says:

>   "The TTL describes how long a RR can be cached before it should be
> discarded."

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.

> RFC 2782 refers to RFC 1035.  The same reference could be used in this
> I-D.

RFC 2782 references RFC 1035 because the reference is in the syntax
section, and RFC 1035 goes into more detail on the wire syntax.  However,
I think RFC 1034 is a better conceptual overview.  If one is not
immediately concerned with the syntax, I therefore think RFC 1034 provides
a better reference, and the meaning given there is functionally the same
as that in RFC 1035.

If I'm missing a reason why RFC 1035 is a better cite, please let me
know.

> I suggest changing that paragraph to:

>   The time-to-live (TTL) is defined in RFC 1035.  The TTL describes how
>   long the SRV record can be cached before it should be discarded.  Any
>   information derived from the SRV record, such as preference ranks,
>   MUST be discarded when the DNS SRV RR is expired.

I now have:

   DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which
   the SRV record information is no longer valid.  As specified in
   [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.

> Quoting the last paragraph of that section:

>   "AFS clients MAY remember which targets are inaccessible by that
>    client and ignore those targets when determining which server to
>    contact first.  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."

> In the "TTL" paragraph, it is specified that any information derived
> from the SRV record must be discarded.  That would include the target.

I've added the word "current" before priority and weight to try to make it
clearer that the client shouldn't just resurrect an old record.  Note that
inaccessibility information is not derived from the SRV record and hence
should not necessarily be dropped with SRV record information.

> In the example in Section 6:

>       "afsdb1               A     172.30.79.10
>        afsdb2               A     172.30.79.11
>        afsdb3               A     172.30.79.12"

> IPv4 addresses from TEST-NET-1 (RFC 5737) can be used:

>        afsdb1               A     192.0.2.10
>        afsdb2               A     192.0.2.11
>        afsdb3               A     192.0.2.12

> Please add an IANA Considerations section that says:

>   This document contains no IANA actions.

Both will be done in the next I-D uploaded after the last call period.  I
was unaware of those two conventions and will be sure to remember them in
the future.  (The last I should have caught from I-D Nits.)  Thanks!

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: SM <[email-masked]>
Date: Wed, 03 Feb 2010 15:04:03 -0800

Hi Russ,
>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.

>If I'm missing a reason why RFC 1035 is a better cite, please let me

You gave a good reason.

>    preference ranks, MUST be discarded when the DNS SRV RR is expired.

I commented on the "SHOULD" above.  The rest of the text looks fine.

Regards,
-sm

---

From: Russ Allbery <[email-masked]>
Date: Wed, 03 Feb 2010 15:27:01 -0800

> 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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Feb 2010 12:02:20 -0500

> 2119, since then it's ambiguous what that is supposed to mean in terms of

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Feb 2010 14:05:21 -0500

--On Thursday, February 04, 2010 01:59:36 PM -0500 Jeffrey Altman 
<[email-masked]> wrote:

> On 2/4/2010 12:02 PM, 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.
>>
>> -- Jeff
>>
> How about?
>
>    AFS clients MAY remember which targets are inaccessible by that
>    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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Feb 2010 14:30:17 -0500

--On Thursday, February 04, 2010 02:20:27 PM -0500 Jeffrey Altman 
<[email-masked]> wrote:

> On 2/4/2010 2:05 PM, Jeffrey Hutzelman wrote:
> Sure.  Context was lost in the thread as the message-ids are not
> consistent. The text I think is being discussed is not actually in the
> draft, it is proposed
> text that Russ put forward on 1 Feb 2010.
>
> How about:
>    the SRV record information is no longer valid.  As implied by
>    [RFC1034], DNS RRs SHOULD be expired after their TTL, and the DNS
>    query repeated.  This applies to DNS SRV RRs for AFS as well as any
> other    DNS RR.  Any information derived from the DNS SRV RRs, such as

How about "Consistent with [RFC1034]..."?

The problem I have with your text that it could be interpreted as merely 
descriptive of 1034, rather than as prescribing a requirement that applies 
to AFS SRV RR's regardless of how you choose to read 1034.

-- Jeff

---

From: SM <[email-masked]>
Date: Thu, 04 Feb 2010 11:34:52 -0800

>2119, since then it's ambiguous what that is supposed to mean in terms of

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:
>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".

>    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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Feb 2010 14:43:06 -0500

--On Thursday, February 04, 2010 11:34:52 AM -0800 SM <[email-masked]> 
wrote:

> 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.

Things have evolved a bit since those days, and while it is clearly 
appropriate to refer to RFC2181 in the context of this discussion, I don't 
think we can expect AFS implementors to know to do so.  We needn't merely 
hope for common sense; we can be explicit, through the use of RFC2119 
requirements language.

> 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".

Looks good to me.  In fact, with this change, I think we can go back to 
MUST, as was in the original text, and which I think is more consistent 
with 1034+2181.  But I don't have strong feelings on this; SHOULD is 
already quite strong.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 04 Feb 2010 13:59:36 -0500

How about?

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 04 Feb 2010 14:20:27 -0500

> That's not the text we're talking about.
Sure.  Context was lost in the thread as the message-ids are not consistent.
The text I think is being discussed is not actually in the draft, it is
proposed
text that Russ put forward on 1 Feb 2010.

How about:

   query repeated.  This applies to DNS SRV RRs for AFS as well as any other

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 04 Feb 2010 14:37:49 -0500

On 2/4/2010 2:30 PM, Jeffrey Hutzelman wrote:
> The problem I have with your text that it could be interpreted as
> merely descriptive of 1034, rather than as prescribing a requirement
> that applies to AFS SRV RR's regardless of how you choose to read 1034.
>
"Consistent with ... " works for me.

Jeffrey Altman

---

From: Russ Allbery <[email-masked]>
Date: Thu, 04 Feb 2010 13:06:23 -0800

> 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".

This looks great.  Thank you!  Adopted for the next version of the I-D.