Subject: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus

From: Thierry Moreau <[email-masked]>
Date: Mon, 06 Mar 2006 21:08:25 -0500

Dear all:

I realized that the DLV scheme has been approved as the
informational RFC4431, and that the DLV RR and the TA RR has been
approved by IANA according to
http://www.iana.org/assignments/dns-parameters . The TA RR
interworking specification is in
http://www.watson.org/~weiler/INI1999-19.pdf .

Does anybody know the details of procedural compliance with
section 3.1 in RFC2929 and section 2 in RFC2434 in these two
cases?

In other words, how were RFC4431 and INI1999-19.pdf reviewed to
ensure that they provided "sufficient detail so that
interoperability between independent implementations is possible"
?

We may observe that both the DLV RR and TA RR are intended to
cope with the situation where the DNS root zone signature is
missing for DNSSEC deployment.

In addition, the recently approved ICANN-Verisign settlement (in
http://www.icann.org/topics/vrsn-settlement/
revised-root-transition-agreement-redline-29jan06.pdf) previously
hoped to "sign and publish the root and ARPA zones commencing in
2005 and completing by 2006," and is now only "commencing in
2006."

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Thomas Narten <[email-masked]>
Date: Mon, 06 Mar 2006 21:06:45 -0500

> interoperability between independent implementations is possible"

Without answering your specific question (I do not know the actual
answer), I'll point out that I (as one of the authors of RFC 2434
responsible for the quoted text) have long considered that text to be
a bug, precisely because it doesn't specify _who_ should do the
evaluation. Clearly, IANA doesn't have such expertise.

Going forward, the proposed text in
draft-narten-iana-considerations-rfc2434bis-04.txt (submitted earlier
today) to address this point is:

>       Specification required - Values and their meaning must be
>              documented in an RFC or other permanent and readily
>              available public specification, in sufficient detail so
>              that interoperability between independent implementations
>              is possible. When used, Specification Required also implies
>              useage of a Designated Expert, who will review the public
>              specification and evaluate whether it is sufficiently clear
>              to allow interoperable implementations.

Thomas