Subject: DNSSEC nearing last call.

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 28 Oct 2003 15:54:22 +0100

namedroppers,

Some time ago I mailed a list with open questions to the list
(http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01532.html).
That list of questions clarified what would be taken as consensus position
of the working group if no further discussion took place. 

I went to the list and marked a large number of questions as resolved
because consensus was reached on them; For those questions for which I
think their may be confusion on why consensus was called I added a
small explanation.

One question (Q15) is still open, but has text in the current document
set that reflects where I think consensus is going. If no further
comments are received on this question it will be marked as resolved
shortly after IETF58.

Since the intro and records document have been stable for a while I
think they are ready for a last call.  I'll wait for some feedback on
this mail but plan to start a WG Last Call on 'intro' and 'records'
before the IETF.  The proto document may have some minor nits to be
fixed but is good for thorough review. We will decide if proto 03 is
ready for last call during IETF58.

Comments about the text (spelling, style) can be mailed to
[email-masked]. Comments about protocol need to go to the
list.

   !!!!!!!!!    Credit goes to the dnssec editors team.  !!!!!!!!!!!!

For clarity the current document-set is:
   draft-ietf-dnsext-dnssec-intro-07.txt
   draft-ietf-dnsext-dnssec-records-05.txt
   draft-ietf-dnsext-dnssec-protocol-03.txt

--Olaf Kolkman
  DNSEXT Co-chair

The list of questions. 
 
 Q1 - resolved
 Q2 - resolved
 Q3 - resolved
 Q4 - mistake in numbering, there is no Q4
 Q5 - resolved (Handled in TCR draft)

 Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"?
      But now encompasses how servers/resolvers should interpret the
      CD bit in the DNS header.  

      resolved, for completeness, the new text in -proto draft
      describes how a caching resolver can have a BAD data cache, and
      when it is appropriate to use it.

 Q7 - resolved
 Q8 - resolved 
 Q9 - resolved

 Q10 - Since there was no response to my message in which I requested
       alternative text
       (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html)
       this item is resolved and the text remained as in proto-2

 Q11 - resolved

       DNSKEY RRs allowed at delegation points.

       After rereading the original threat on this issue we decided
       that the working group consensus is that DNSKEY RRs not allowed
       at delegation points.  

       This is reflected in the last line of proto section 2.1.

 Q12 - resolved

 Q13 - resolved
  
       The silence on the list has been interpreted as consensus for
       keeping the advice that caching should be atomic (i.e. entire
       response keyed to a single <sname,sclass,stype>) is discussed in
       protocol draft (as a SHOULD).

 Q14 - resolved

 Q15 - Open

        Should a security-aware stub resolver be allowed to set the CD
        bit on queries or should this behavior be prohibited?

        The -proto document now reflects:
       *It should remain SHOULD NOT. security risk given to state why
        it is a bad idea for general operation*

        This will be taken as the consensus position if no further comments
        are received by the end of IETF58.

 Q16 - resolved

       What should a recursive nameserver do if query has flags CD=1, and
       DO=0? Suggest

       Text suggested in the original question
       (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01559.html).
       suggested a change in protocol. Working group concensus is against this.

       In proto the two bits are treated separately and their behavior is
       'orthogonal'.

 Q17 - resolved
      (the TCR document handles this)

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

--
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/>