Subject: DNSSEC-bis: DONE.

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 28 Jun 2004 08:15:15 +0200

Dear Colleagues,

Time to wrap up.

DNSSEC-bis will go through one final iteration of editing and will
then be shipped to the IESG.

The chairs point of view is that there is consensus on shipping the
DNSSEC-bis docs without the need for modifications to allow for a
smooth transition to a system of denial of existence that does allow
for more privacy. Some of the proposals to allow for 'more space' for
transition have not gathered consensus.

Below is a somewhat detailed explanation on how and/or why reached a
conclusion on some of the major issues related to future transitions.

  - DNSKEY Flag; specifying behavior for certain settings of 
    the protocol fields and keyflag field
    (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00955.html)

  and 

  - nssec-records ISSUE: don't make NSEC a protocol requirement
    (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01199.html)

    The WG members have argued that both these proposals may cause
    changes in the security model. There is _no_ consensus on the fact
    that these proposals will _not_ cause problems. In fact, for the
    nsec-records issue there seems to be consensus that the proposal
    will cause problems. 

    From the discussion on the mailing list the chairs are convinced
    that these changes can not be adopted without actually testing the
    proposals in a workshop environment. There is no time for this. 

    To provide the one line summary: There is no rough consensus for
    forwarding and there is no time to continue working on these issues.

  - Concerns with TCR as a transition mechanism

    (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01191.html)

    This discussion concluded with the sense that although the
    proposed TCR mechanism may not be that flexible, it provides a way
    forward for the expected deployment path.
    
  - dnssec-protocol ISSUE: permit DNSKEY's at all owner names

    (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01200.html)

    There is consensus that the specification should not limit
    where DNSKEY RRs are to appear. The text provided in 
    http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01229.html
    seems to phrase the 'exceptions' properly.

We realise that if we would allow for more time, time to think, time
to modify the docs, time to modify code and time to test the code, we
may have been able to come up with the perfect transition mechanism
for any variety of future DNSSEC bis. We think the WG realises with us
that the WG does not have that time.

                            ---

We would like to thank the working group for their positive and
constructive attitude towards overcoming this hurdle. A number of
people, we do not mention names to avoid missing people, have been
successful in keeping the discussion focused, bringing solid technical
arguments to the table and finding minor inconsistencies in the docs
even after last call.

                            ---

We allow the editors to make the last modifications and publish a new
revision. These revisions will be send to the IESG shortly (order
day-days) after they appeared in the drafts repository. There will not
be any last call.

                            ---

You will see the documents shipped to the IESG with a short writeup.
(cf. http://www.mip4.org/2004/draft-writeup-items.html). We have
assumed during this process that everybody in the group is aware of
RFC3668 and we are not in for late surprises with respect to IPR
disclosure.

--Olaf and Olafur
  DNSEXT chairs.

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