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@xxxxxxx> 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@xxxxxxxx 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@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf