Subject: TSV-DIR review of draft-allbery-afs-srv-records-03

From: Joe Touch <[email-masked]>
Date: Tue, 02 Feb 2010 14:32:27 -0800

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 [email-masked] if you reply to or forward
this review.

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.

Joe

-----

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

--

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

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

--

(OPTIONAL)

The phrase "This attack can be ameliorated" might be more accuratly
described as "This attack can be prevented".

-----

---

From: Russ Allbery <[email-masked]>
Date: Wed, 03 Feb 2010 18:21:17 -0800

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.

> 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
> [email-masked] if you reply to or forward this review.

Thank you!

>    the record would look like in a hypothetical future if such a

Thanks, I've made this update in my version and it will be in the new I-D
uploaded after the Last Call period.

> dynamic port (e.g., 65535). The accompanying text describing the example

Thanks, I've made this change (although using 65500 to avoid the
highest-numbered port, since sometimes those are treated specially).

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

> described as "This attack can be prevented".

Thanks, changed.

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