On Thu, Aug 23, 2007 at 04:12:05PM -0400, The IESG wrote:
- 'DNSSEC Lookaside Validation (DLV) IANA Registry'
<draft-weiler-dnssec-dlv-iana-00.txt> as an Informational RFC
1. Should it be published?
The draft should not be published for at least the following reasons:
o Means of Trust Anchor Publication
Even if we assume that the root zone will not be signed in the near future
and a Trust Anchor Repository (TAR) was desirable, it is not clear that DLV
would be the publication mechanism of choice. In fact, given that DLV is
designed to follow the DNS tree structure by locating the trust anchor closest
to the target zone, a flat, TLD only DLV structure seems counter-indicated.
Other means of publication, e.g. a signed list of DS records or a DNSSEC
enabled version of the root zone would be easier to maintain and access.
o Incompleteness of Instructions
The draft says
IANA is instructed to use its own best practices for authenticating
zone operators' requests to insert, modify, and delete DLV entries.
Except for some additional guidance on DNSSEC key parameters in
subsequent paragraphs, the main operational questions are not even touched
in this document. This includes the lack of a termination criterion or
exit strategy.
o Nature of Request
The draft requests the creation of a domain within the ARPA top level domain,
which is governed by RFC 3172, also based on MoU RFC 2860:
Section 4.3 of RFC 2860:
4.3. Two particular assigned spaces present policy issues in addition
to the technical considerations specified by the IETF: the assignment
of domain names, and the assignment of IP address blocks. These
policy issues are outside the scope of this MOU.
Note that (a) assignments of domain names for technical uses (such as
domain names for inverse DNS lookup), (b) assignments of specialised
address blocks (such as multicast or anycast blocks), and (c)
experimental assignments are not considered to be policy issues, and
shall remain subject to the provisions of this Section 4. [...]
In addition to the apparent lack of reference to RFC 3172 in the draft,
it is not necessarily clear that domain names corresponding to TLDs are
covered by the exceptional clause (a) above. Quite to the contrary, the
fact that the instructions try to exploit IANA's existing relations
to TLD registries/managers favor the view that it is clearly the non-IETF
part of IANA that is addressed here. That said, an IANA considerations
section is the wrong place for such request.
The formalities would only insignificantly change by re-homing from
dlv.dnssec.arpa to another TLD, since the IETF<->IANA relation is still
governed by RFC 2860.
This is not meant to say that IANA could not operate and maintain a TLD
TAR or that the IETF could not encourage such effort. Just the means of
communication needs to be different. If the IETF believes an interim
solution like a TLD TAR is desirable _and_ IANA is the preferred TAR
operator, it should approach ICANN through the appropriate liaison channels.
Still that would not imply use of the DLV technology.
Just as additional data point: there's work going on within RIPE to explore
the requirements for and properties of a TLD only TAR.
-Peter (no hats, speaking for myself only)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf