Unfortunately Olafur's process did not set out the procedure for dealing with any changes to the draft. Setting asside step 3 which we can anticipate meeting Hobbes' description of the life of a man in a state of nature, how do we proceed with the document in the meantime? If as appears to be the case these are all editorial issues that can be dealt with in the normal post-last call process, should we wait for an updated draft before going into last call or consider the period prior to Feb 12th as being a preamble to last call and deal with all the issues at once? Since the Feb 12th date was not described as a last call are we now required to repeat the last call and then comment in that period again or do the comments already made count for that purpose? Or considering that no objections were raised in last call and only minor editorial issues with the document were raised in the Feb 12th period do we simply resolve the outstanding issues and go ahead with submission to the IESG? Phill > -----Original Message----- > From: David Blacka [mailto:davidb@verisignlabs.com] > Sent: Thursday, February 13, 2003 2:27 PM > To: Ted Hardie; namedroppers@ops.ietf.org > Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in > > > On Thursday 13 February 2003 12:45 pm, Ted Hardie wrote: > > > Note that David and Rob's reply dealt with the issues around section > > 3.1.1. I have seen no replies about the concern raised about > > section 7 (more explicit text on the interaction of opt-in and > > NXDOMAIN). I know Roy has done some pretty extensive thinking on > > it, but that is not yet in the draft. Others may disagree that it > > is needed, but no one said so explicitly. > > I haven't forgotten your concern, Ted. I haven't commented on it yet > because I haven't thought about it enough. > > > The workshop reports also indicated that the document didn't agree > > with implemented behavior in regards to NXT and needed to recommend > > against dynamic update; > > Yes, I am aware of these issues as well. I apologize for not having > posted an open issues list to namedroppers by now (see the end of this > message, however, for one). > > At this point, however, I do not believe recommending against dynamic > update with Opt-In is correct. I don't think there is a real conflict > between them. But dynamic update should be mentioned in the draft. > > > There was also the discussion among Rob, Johann, and Michael about > > the need to rev NXT (and possibly SIG and KEY) to make the current > > infrastructure distinguishable from the previous infrastructure. I > > didn't say a resolution to this (though I may have missed it in a > > thread permutation). > > This issue is totally orthogonal to Opt-In. I think you haven't seen > a resolution to this issue because there hasn't been one. > > > There are two possible outstanding editorial issues concerning > > section 7 >and section 3.1.1 but these are not rated as being > > significant enough to >prevent progress of the document. Please add > > the dynamic update and NXT issues to this list. I'm most concerned, > > obviously, about the mismatch between tested implementations and the > > spec on the NXT issue. > > The workshop summary was somewhat unclear on the NXT issue. It is far > from a major one. Essentially the draft forbids sending the negative > wildcard proof NXT when sending an NXDOMAIN response. We had two > server implementations for opt-in: one which sent the negative > wildcard proof and one that didn't. Both worked. So the draft is > using a MUST when it should be using either SHOULD or MAY. This was > actually suggested by Ed Lewis before the publication of the -04 > version but got missed somehow. > > > >So the question for the chairs is what do we do next? > > > > Speaking personally, I think the authors should rev the > docs to fix these > > spec bugs. > > I, as one of the authors, agree. I believe that the other authors > (Mark and Roy) also agree. > > To summarize the "spec bug" issues list that I am aware of: > > * change the MUST NOT send negative wildcard proof to a SHOULD NOT > or MAY NOT (or some other language that means the same thing). > > * Clarify opt-in behavior wrt dynamic update. (although I'm not > sure what the clarification should say). > > * In section 3.1.1, make it clear that a violation results in a > validation error. > > * Various additional warnings and comments to be placed in the > Security Considerations section. This includes: > > o something about NXDOMAIN (although I'm not sure what needs to be > said about this). > > o some additional description of domain hijacking possibilities > (asked by Paul Vixie during the Atlanta dnsext meeting). From > the minutes: > > There was a comment that security section needs stronger > language, Clearly list the need for zone transfer protection and > risk from zone hijacking of opt-outed delegations. Authors > agreed examine if the current text is insufficient . > > Anything else? > > I'd like to point out that none of these proposed changes should > affect existing implementations in any way. > -- > David Blacka <davidb@verisignlabs.com> > Sr. Engineer Verisign Applied Research > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> >
Attachment:
smime.p7s
Description: application/pkcs7-signature