Subject: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 2 Oct 2009 09:20:48 -0400

I have a rather minor suggestion for the DNSSEC algorithm registry from the
discussion in Section 3 and 4 in draft-ietf-dnsext-dnssec-algo-allocation.
The sections describe the changes to be made to the DNSSEC algorithm
registry but I think it might be better to include the status (i.e.
MANDATORY, OPTIONAL, etc.) of each algorithm, not just the reference.

Currently, only the RSA/MD5 allocation gives a direct indication that it is
deprecated in the registry table, unlike the DS digest registry table.
Implementers would have to check the references to insure the current state
of all the algorithms.  Would it make more sense to add another column to
the registry with the current status?  The status of non-standards track
algorithms should be OPTIONAL by default, with a status change to MANDATORY
only done via a standards track doc.

Does this seem like a good idea, or makes the registry more complicated?
Scott

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Oct 2009 10:05:21 -0400

No hat.

> Does this seem like a good idea, or makes the registry more complicated?

"Yes".  In fact, change the "or" to "and".  Just because it makes the
registry more complicated does not make it a good idea -- in this
case, it increases maintenance cost for the considerable benefit of
making the registry much easier to use.  I think it makes sense.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 Oct 2009 10:13:28 -0700

>making the registry much easier to use.  I think it makes sense.

+1

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Oct 2009 11:14:11 -0700

>MANDATORY, OPTIONAL, etc.) of each algorithm, not just the reference.

Just to be clear on my previous "+1": I think this is a good idea for the registry, but *not* for draft-ietf-dnsext-dnssec-algo-allocation. That is, the draft should have the single focus of what level of RFC is needed for the registry.

A side-effect of that was the discussion that the registry should track the standards level of the RFCs that cause the registration. This is quite different than tracking the status of an algorithm. In order to determine the latter, you have to choose which RFCs get to be definitive, and that opens a whole new can of worms.

If someone wants to write a new draft saying how the IANA registry should mark the requirements levels for algorithms, that's great: I just don't think it should be in draft-ietf-dnsext-dnssec-alg-allocation.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Oct 2009 15:22:39 -0400

On Mon, Oct 05, 2009 at 11:14:11AM -0700, Paul Hoffman wrote:
> 
> If someone wants to write a new draft saying how the IANA registry
> should mark the requirements levels for algorithms, that's great: I
> just don't think it should be in
> draft-ietf-dnsext-dnssec-alg-allocation.

That sounds like a nice suggestion for a housekeeping draft.  Any
volunteers?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 6 Oct 2009 08:00:05 -0400

Well I brought it up, so I guess I should volunteer.    I'll try and beat
the deadline for -00 drafts.

Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Oct 2009 09:47:50 -0400

> the deadline for -00 drafts.

Thanks!

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.