Quoting in full to get the original message to the afs3-standardization
list, since the original message had a typo in the e-mail address.
Joe Touch <touch(_at_)ISI(_dot_)EDU> writes:
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir(_at_)ietf(_dot_)org if you reply to or forward this review.
Thank you!
The document defines a DNS SRV RR alternative to a DNS AFS RR. Because
the AFS RR is basically a subset of the information in an SRV RR, this
is fairly straightforward.
I found no transport issues of note in this document.
I also had some minor suggestions noted below that focus on language and
the examples provided, as noted below. I recommend correcting the port
example; all others are optional and provided as constructive input
only.
--
(OPTIONAL)
The following paragraph uses the term "theoretical" where either
"hypothetical" or "currently undefined" might be more appropriate. The
last sentence might also benefit from a small mod. The original text is:
afsdb3 provides a theoretical TCP version of AFS VLDB and PTS service
on the standard ports and is the only server providing these services
over TCP for this cell. Such a TCP-based AFS protocol does not exist
at the time this document was written. This example only shows what
the record would look like in a hypothetical future when such a
protocol had been developed.
The proposed version (word wrap needs final adjusting) is:
In the example, afsdb3 provides a (currently undefined) TCP version
of the AFS VLDB and PTS services on the standard ports and is the
only server providing these services
over TCP for this cell. Such a TCP-based AFS protocol does not exist
at the time this document was written. This example only shows what
the record would look like in a hypothetical future if such a
protocol were developed.
Thanks, I've made this update in my version and it will be in the new I-D
uploaded after the Last Call period.
--
(RECOMMENDED)
In Section 6, there is an example of several SRV records. Most use IANA
values for the described services (7002, 7003). One is intended to
demonstrate that the IANA value can be overridden in the SRV, and uses
the value 7008; however, this value is assigned by IANA for afs3-update.
It would be preferable to use a different port as an example, notably a
dynamic port (e.g., 65535). The accompanying text describing the example
should also be updated.
Thanks, I've made this change (although using 65500 to avoid the
highest-numbered port, since sometimes those are treated specially).
(OPTIONAL)
The same example also includes A records for afsdb1, afsdb2, and afsdb3.
As recommended by RFC-3330, these examples should use the addresses
reserved for examples, i.e., 192.0.2.0/24, rather than addresses
reserved for internal use (as in the current text).
This will be done in the next I-D. I had been unaware of that reserved
space.
--
(OPTIONAL)
The phrase "This attack can be ameliorated" might be more accuratly
described as "This attack can be prevented".
Thanks, changed.
--
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