Subject: Section 4 of dnssec-protocol-03

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Oct 2003 12:36:28 -0500

Comments:

Section 4, page 20.  "Trusted starting point".  A more precise term might 
be "trust anchor".

Page 20, para beginning "A security-aware resolver..." delete  "MUST be 
capable....key, and" - the latter clause includes the meaning of the 
indicated clause.   Add at end of para "However, such mechanisms are out of 
scope for this document."

And the meat of the matter:  Would it make sense to add a second bit 
mirroring the DO bit to indicate a new DNSSEC query rather than an old 
DNSSEC query?   DO would indicate an old DNSSEC query, DX would indicate a 
new query.  E.g. how do we handle the legacy case?  *sigh*

Mike

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mike StJohns <[email-masked]>
Date: Fri, 31 Oct 2003 11:20:55 -0500

At 10:36 AM 10/31/2003, Mike StJohns wrote:
>At 10:28 AM 10/31/2003, Samuel Weiler wrote:
>>On Thu, 30 Oct 2003, Mike StJohns wrote:
>>
>> > ... we changed all the type codes to prevent problems with legacy
>> > systems - might it not make sense to make the hard separation
>> > include stub to recursive resolver signalling?  Its one bit in the
>> > EDNS0 header.
>>
>>I find it interesting how questions that have been discussed at
>>length, including in last-called and IESG-approved documents (albeit
>>ones not yet out of the RFC editor's queue), keep getting raised.

Yup.  But this document is supposed to represent a complete compilation of 
all the little twiddles in the virtual forest of documents making up the 
DNSSEC stuff.  And a *replacement* for those documents - e.g. when 
complete, this document will represent ground truth and the other documents 
will be deprecated.  So by the normal standards process, its legitimate to 
give this a second look.  I don't mind treating it as settled though - I 
mentioned it because it seemed strange to change one thing without changing 
the other.  So leave it as is and lets move on.

>>See section 2.3 of the TCR draft, which went to IETF last call on July
>>16th and was approved for publication on 21 August.  If the standards
>>process is letting documents through with too little review, then we
>>have bigger problems than a header bit will fix.

Actually, what the current -05 version of this (-03 was what was submitted 
to the IESG) says is "
It could, though,
    be considered in addition to changing the RR type codes."
referring to adding a second DO type bit.  It didn't actually make a 
decision except by not mentioning it further.

>>-- Sam