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. 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". -----
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf