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.
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".
-----
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf