On Fri, Dec 16, 2005 at 10:23:59AM -0500, Daniel Senie wrote: > I wasn't. Just reviewed it. Basically is what I personally believe is > the correct and sufficient solution. That it's in the queue of > another WG does, I think, strengthen my argument that the draft under > discussion in DNSOP is in fact not a good requirements document.
I have reviewed draft-ietf-dnsop-serverid-05.txt, and I actually had an opposite reaction to that outlined above: it seemed to me that it _was_ a good requirements doc, because it first set out what the current support is, and then outlined (in section 3) why that is inadequate for the purposes. In particular, it points out that a subsequent request from the same resolver will not necessarily provide good information about the service queried by some previous resolver request. That seems to me to motivate the requirement in 3.1, which is that there must be some mechanism to allow for the identifying information to be part of a normal query. (This also strikes the right balance in not requiring that the information _always_ comes back, since such information might break existing resolvers.) I do have an editorial nit about this doc, BTW, which is that the references don't seem to be in it (or at least, not the copy I read, which is at <http://www.ietf.org/internet-drafts/draft-ietf-dnsop-serverid-05.txt>). There's a reference to [RFC3258] on p2, a reference to [BIND] on p3, and a reference to [RFC1034] on p4. Other than that, I support this document going forward. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x4110 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
