Advance request for opt-in and experiments

["Olaf M. Kolkman" <[e-mail]>]

Hello Mark,


This is a proto request for two documents. Olaf Kolkman will be
the shepherd for both.

Please publish draft-ietf-dnsext-dnssec-experiments-03 on the standards
track and publish draft-ietf-dnsext-dnssec-opt-in-09 as an experimental
rfc.


Questions:

1) Have the chairs personally reviewed this version of the ID and do
     they believe this ID is sufficiently baked to forward to the IESG
     for publication?

Yes we have reviewed both document.


2) Has the document had adequate review from both key WG members and
     key non-WG members? Do you have any concerns about the depth or
     breadth of the reviews that have been performed?

Yes.

draft-ietf-dnsext-dnssec-opt-in has quite a long history and thorough
and in-depth discussion a few years ago also see below. Both opt-in
and dnssec-experiments have been last called together and were
reviewed (among others) by:

Sam Weiler
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00576.html)
Ed Lewis
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00440.html)
Andrew Sullivan
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00330.html)
Mark Kosters
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00309.html)
Thierry Moreau
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00305.html)
Scott Rose
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00316.html)
Rodney
Joffe(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00335.html)
Thomas Nartan (thread starting at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00308.html).


3) Do you have concerns that the document needs more review from a
     particular (broader) perspective (e.g., security, operational
     complexity, someone familiar with AAA, etc.)?

No we do not.

4) Do you have any specific concerns/issues with this document that
     you believe the ADs and/or IESG should be aware of? For example,
     perhaps you are uncomfortable with certain parts of the document,
     or whether there really is a need for it, etc., but at the same
     time these issues have been discussed in the WG and the WG has
     indicated it wishes to advance the document anyway.

It is probably good to have some historic background on the documents.

The OPT-in document has been around for a long time. In 2002 it lead
to heated debates which resulted in a conclusion that opt-in was
technically solid but there was no rough consensus to add opt-in to
the spec.
(http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01007.html)

The chairs then suggested to make sure that opt-in did not end up as
an I-D tombstone but was to be published as informational
draft. Adding the boilerplate has been on the WG todo list for a very
long time.

In the mean time the working group has created DNSSECbis and has
thought about the possible transition mechanisms to DNSSEC-ter (for
deploying NSEC3).  One of the possible transition mechanism can also
be used to run experiments on production systems without interfering
with production data. This technology has been described in the
dnssec-experiments draft.

After dnssec-experiments was published as an I-D, the editors of
OPT-IN (also the editor of opt-in) suggested to update OPT-IN to fit
in the frame work of dnssec-experiments, in other words opt-in being
the first application of dnssec-experiments.

Currently the OPT-IN technology is making its comeback in the NSEC3
specification. Times seem to have changed since OPT-IN does not seem
to be as contentious as 4 years ago.


5) How solid is the WG consensus behind this document?  Does it
     represent the strong concurrence of a few individuals, with others
     being silent, or does the WG as a whole understand and agree with
     it?

We think it is solid. Active members are aware of this document and
key members of the working group have reviewed the documents. There
were no objections raised against the document. There was some
clarification work needed after version of 'experiment' and version 8
of 'opt-in.


6) Has anyone threatened an appeal or otherwise indicated extreme
     discontent?  If so, please summarize what are they upset about.

No. See the history above.

7) Have the chairs verified that the document adheres to _all_ of the
     ID nits?  (see http://www.ietf.org/ID-nits.html).

yes

8) For Standards Track and BCP documents, the IESG approval
     announcement includes a writeup section with the following
     sections:


draft-ietf-dnsext-dnssec-experiments

This document describes how algorithm identifiers can be used to
perform experiments within a DNSSECbis environment without that the
published data is marked as "bogus" by validating resolvers that do
not partake in the experiments.

The document explains why this methodology works and describes how
experiments are to be defined.

Besides, it suggests that algorithm identifiers can be used to
introduce non-backward compatible DNSSEC features into the
protocol.

The first application of this methodology will be an experiment with
"opt-in" [draft-ietf-dnsext-dnssec-opt-in]. It is possible that the
methodology will be used for the introduction of current DNSSEC
extensions currently under development in DNSEXT, the NSEC3 work.


draft-ietf-dnsext-dnssec-opt-in

opt-in is a method to disable the authenticated denial of existence
for a range of domain names in a zone. It has been developed to
generate a sparse set of NSEC RRs in a zone that contains mostly
delegations i.e. to opt-in the secure delegations. The span of
delegations for which authenticated denial is not available is still
indicated using an NSEC resource record.  'NSEC-bit' in the type
bitmap of the NSEC RDATA is used to signal the different semantic of
the opt-in type NSEC RR.

opt-in is a methodology that is backwards incompatible with DNSSEC; in
order to perform a trial the methodology described in
draft-ietf-dnsext-dnssec-experiments is applied.



--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/