May 11, 2006, at 4:11 PM, Thierry Moreau wrote:

Dear co-chairs and wg members:

I regret to post the present message against progression of DNSEXT
WG document I see two
difficulties with this draft, related to the IETF document
development process.

Although we have not issued a last call yet I will take this note as
input for a "nay" during last call.

The wording used in the section 5.2. (No Intellectual Property
Encumbrance) is such that the DNSEXT WG commits itself to make
factual verifications about the presence and/or validity of IPR
claims, which is a WG activity not compliant with RFC3979.

I think that Wes Hardaker's suggested modification to the text fixes
this; the working group then only has to check on "known encumbrance"
which is essentially "verifying against the IPR database".

The other issue with the document is that it goes beyond the DNSEXT
chartered work. Specifically, the charter mandates DNSEXT to
"Define a method for automated rollover of trust-anchors configured
in validating resolvers." Instead, the requirements document
address trust anchor key management on a broader perspective, as if
the charter might be revised as a consequence of revisiting the
trust anchor key functions in the DNSSEC protocol specifications.

In going beyond its specific automated rollover mandate, the DNSEXT
envisions solutions outside of DNS protocol extensions, again in
possible conflict with the DNSEXT charter.

You have lifted a specific line from the charter: "a method for
automated rollover of trust-anchors configured in validating
resolvers." I would like to quote the full context:

The WG works on solutions for DNSSEC deployment issues that may
require protocol modifications. Two of these issues are identified
and are worked on under the umbrella of this WG. 1] (a) method(s) to
prevent the possibility of trivial zone enumeration and 2] a method
for automated rollover of trust-anchors configured in validating
resolvers.

In my opinion the working group is not overarching since we are
trying to sort out solutions for DNSSEC deployment issues that may
require protocol modifications.

There might be a group willingness to proceed along the lines
explained above. However, the IETF standards development process is
a structured activity, and wandering of a WG outside the process
rules and/or its chartered work may be coerced by the groups in
charge of IETF activities overseeing (if I understand correctly,
this would be the IESG if and when the draft is approved at the WG
level).

What should have been done in the preparation for a requirement
document for automated trust anchor key rollover is to define the
very issues as faced in the DNSSEC protocol environment,
contemplating the set of possible DNS protocol extensions for
rollover purposes, with the known limitations of the DNS
architecture. As a consequence, the requirements document might
have come to inescapable security considerations expected from any
trust anchor key rollover solution. If I recall correctly, the WG
chairs expressed the view that the requirement should also define
"metrics" against which trust anchor key rollover solutions would
be evaluated.

We did. I would like to ask the working group if they think that that
will be a useful exercise. Personally I think it be a difficult task.
I propose that we "fix" the rollover requirements document and that
we start looking at the separate proposals and see which ones meet
which requirements. From that we can probably isolate 1 or 2 on which
we then will further debate.

These issues were privately raised to the DNSEXT WG co-chairs,
without feedback. In WG discussion about the previous version of
the document , I
expressed my opinion about the section 5.2. (No Intellectual
Property Encumbrance), and I otherwise abstained from making
contributions towards advancement of the draft, based on the
assumption that the WG discussions on a draft going beyond the WG
charter would be unproductive.

I have invited you to contribute to the working groups requirement
document. I understand that you consciously abstained, so noted.

thanks,

Kolkman

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

PGP SIGNATURE
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.

xx80Ua/sZriekQZ2vQvBaSo=
=Zq5y
PGP SIGNATURE