Re: Last Call: draft-weiler-dnssec-dlv-iana (DNSSEC Lookaside Validation (DLV) IANA Registry) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]