SM <sm(_at_)resistor(_dot_)net> 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 (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf