Dear colleagues, In Philadelphia, I volunteered to review draft-ietf-dnsop-as112-ops-01. This is that review.
General: I have read the draft. I think it is a sensible draft that documents an important part of the DNS infrastructure. I think it is well-written and clear. I have not been personally involved with the operation of an AS112 node (other than, in a previous position, saying, "Yes, that seems like a good idea to me," which hardly qualifies), so I cannot confirm that the document is correct in all its details. That said, it looked reasonable to me, and I worked out what to do to implement this "on paper", and didn't notice any gaps. I have some particular observations, below. None of them strikes me as an important objection. Other than those remarks, I think this draft is ready to go. Abstract: "Examples are the addresses designated in RFC1918 for private use within individual sites." I might change this to, "Examples include." Section 1: As in the Abstract. Also, while I was working on another document, a reviewer pointed out to me that the term "reverse DNS query" could be misinterpreted to be referring to IQUERY operations. That approach is formally deprecated in RFC3425. I therefore suggest changing Devices in such environments may occasionally originate reverse DNS queries [RFC1034] corresponding to those private-use addresses. to Devices in such environments may occasionally originate DNS queries for reverse map entries [RFC1034] corresponding to those private-use addresses. or something similar (I'm sure those better with English prose than I will be able to make the above more elegant). I'm not sure whether that reference to [RFC1034] is needed in this formulation, but it may be. Section 2.1: Would there be any benefit to creating a registry for the zones that should be covered by AS112? I assume not, because the reservation of the address blocks in question is already well-defined; but I thought I'd ask anyway. Section 3.3: A host which is configured to act as an AS112 anycast node should be dedicated to that purpose, and should not be used to simultaneously provide other services. Is that intending to suggest restrictions on the host strictly speaking (which is how it reads now to me); is it really intending to say, "Don't run other zones using the same DNS server"? A sentence on what problem using a dedicated box solves (I think I know, but I want to be sure) might be helpful. Section 3.5: Although the queries received by AS112 nodes are definitively misdirected [. . .] Should that be "definitely", or something else? I'm not sure what the "definitively" is for there. (You could leave it out, in fact.) Section 6: I recall some previous discussion about whether a document is needed that specifies the ways where some future requirement to serve other zones might be satisfied. I recall for certain that it was ruled out of scope for this draft (and I agree). What I cannot recall is whether there was any promise of such a draft, and a reference from this document; or whether the plan was instead just to be silent on it. I do worry slightly that the text, "Such changes would be widely announced in operational forums, and published at <http://www.as112.net/>," amounts to a commitment on the part of the authors about how such a change would in fact be managed (and I'm not sure anyone's in a position to make such a commitment). I wonder if perhaps the "would" in that sentence ought instead to be "should" or "ought to be" or something like that. Best regards, A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
