On Mon, 26 Jul 2004, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > Hmm, the revision number does not seem to be incremented from the > previous one: > [...] > But there appear to be differences between the two documents > (non-trivial ones such as the issue date).
I'm not sure what happened. I definitely submitted -03 to [EMAIL PROTECTED], but it showed up as -02. > And from a quick glance, > the new version does not seem to address my comments on the previous > one: > http://darkwing.uoregon.edu/~llynch/dnsop/msg02958.html > > If this simply means the author decided to reject the comments, then > it's okay (though I'll be sad then). But at least I've not seen any > responses to the comments, either positive or negative, so I'm making > an explicit note just in case. I did see your comments and I thank you for sending them. I apologize for not responding to them until now. Please see below for my response. On Tue, 29 Jun 2004, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > (explicitly cc'ing to the authors) > > >>>>> On Thu, 24 Jun 2004 13:04:08 -0700, > >>>>> David Meyer <[EMAIL PROTECTED]> said: > > > The WGLC on this one was scheduled to end today at 1500 > > PDT (GMT/UTC-7). However, there have been several > > comments that need to be resolved before we can go > > forward. We will revisit this one after the authors have > > revised the document. > > In section 2.2.1, the draft says: > > [...] > Implementations that perform lame server caching MUST refrain from > sending queries to known lame servers based on a time interval from > when the server is discovered to be lame. [...] > > In general, I agree on this recommendation. But it might cause a > rather undesirable result when all authoritative servers seem to be > lame, since some authoritative server implementations can be lame for > particular resource record types. (See Section 4.4 of > draft-ietf-dnsop-misbehavior-against-aaaa-01.txt for more details) > > Of course, what is wrong here is "lame" authoritative servers. But > sometimes we need to explore workaround to deal with real-world's > problems... This is true and I overlooked this comment during the revision. You're right that a sentence or two explaining the unfortunate "lame by domain name" behavior would be helpful. > Meanwhile, I'm not sure if the recommendation also applies to the case > where *all* authoritative servers seem to lame. In the beginning of > Section 2.2, the draft says as follows: > > A more common occurrence is a subset of a zone's name servers being > unavailable or misconfigured. > > But I could not be sure if this section (including the recommendation) > only concentrates on the case where a subset of the servers behave > badly or it also considers the case where all of them are bad. > > If the intention is the former, then please make it clear throughout > the section, particularly in Section 2.2.1. > > If the intention is the latter, I hope the document also notes that > the recommended behavior may sometimes cause undesirable result while > the behavior generally makes sense. The section is intended to apply on a per-server basis, i.e., what to do when a given server is discovered to be lame for a particular zone. I confess that I re-read the section several times and thought it was clear. I could not figure out a way to make it more clear. Could you please suggest specific changes? Matt . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
