[AFS3-std] Re: TSV-DIR review of draft-allbery-afs-srv-records-03

[Russ Allbery]

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@ISI.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@ietf.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@stanford.edu)             <http://www.eyrie.org/~eagle/>