Subject: Forwarding report for wcard-clarify

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sun, 30 Oct 2005 23:20:42 -0800

Dear Margaret,

Hereby the report for draft-ietf-dnsext-wcard-clarify-09. The DNSEXT
working group requests that this document it to be published on the
standards track.

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, both of them. This draft has been carefully written, it provides
a clear motivation and has its topics have been worked out thoroughly.

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, it has been thoroughly reviewed and we have no concerns.

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.)?

We have no such concerns.

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.

The document updates RFC1034 (full standard), although the file-name
suggests otherwise this is not _only_ a clarification document. (This
is clear from the title, abstract and introduction)

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?

This document has seen two last calls in its lifetime. One concluded
with overall consensus that the document is fulfilling a need but also
identified a few open issues. After these were addressed a new last
call was issued. We believe that the consensus is solid.

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

Not that we are aware off.

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:

     - Technical Summary
     - Working Group Summary
     - Protocol Quality

This document started out as a clarification of the behavior of
wildcards. In order to be able to understand the excact methods to
proof the non-existence of matches against a DNS query in the context
of DNSSEC, a good description was needed.

It was intended to add the description herein as an appendix to the
DNSSECbis specification but since this document updates RFC1034 it was
thought that it better stands on its own.

Another purpose of this document is to clarify behavior that is often
misunderstood and clearly identify the limitations of wildcard
use. The document is consciously verbose in its descriptions e.g. in
order to describe the behavior the terms closest encloser is
introduced.

The document introduces a change to the case where a CNAME RR is owned
by a wildccard record.  (*.foo.example CNAME bla.example). A strict
interpretation of the algorith would imply that CNAME substitution
would not take place. This document changes this part of the
specification and makes the interaction the same as with other
wildcard owned records of other types. Most implementations already
behave as is specified in this document.

Further more the document  assesses the behavior of wildcard in the
presence of Resource Record types that are part of the "control plane"
of the DNS.

Although the document started of as "a DNSSEC bis appendix" it has
matured into a stand-alone document.

The document for this document will be shepherded by Olaf Kolkman.

Olaf and Olafur

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