Re: [dnsext] experimental/testing DNSSEC algorithm identifiers

Edward Lewis <Ed.Lewis@neustar.biz> Wed, 12 August 2009 14:33 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94AE83A6AE0; Wed, 12 Aug 2009 07:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.695
X-Spam-Level:
X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDPDuH0ti6uu; Wed, 12 Aug 2009 07:33:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9108A3A6A6C; Wed, 12 Aug 2009 07:33:46 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1MbEov-000IPP-8R for namedroppers-data0@psg.com; Wed, 12 Aug 2009 14:28:53 +0000
Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Ed.Lewis@neustar.biz>) id 1MbEoq-000IOT-0V for namedroppers@ops.ietf.org; Wed, 12 Aug 2009 14:28:51 +0000
Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n7CERsMu013952; Wed, 12 Aug 2009 10:27:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240800c6a86d07f114@[10.31.200.194]>
In-Reply-To: <4A827535.9060400@NLnetLabs.nl>
References: <4A827535.9060400@NLnetLabs.nl>
Date: Wed, 12 Aug 2009 10:26:34 -0400
To: Jelte Jansen <jelte@NLnetLabs.nl>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: [dnsext] experimental/testing DNSSEC algorithm identifiers
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

At 9:54 +0200 8/12/09, Jelte Jansen wrote:

>Any thoughts?

In summary - I have doubts about the future of this proposal, no 
matter how worthy it is.

Why I am being a grump:

We (DNSIND/DNSEXT WGs)'ve had a bad experience with proposals to 
allocate "general pool" numbers.  There is the Kitchen SINK RR 
(RRType = 40, 
http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02) and a 
generic key application for the old KEY RR 
(http://tools.ietf.org/html/draft-lewis-dnsext-key-genprot-00).

(Okay, those both wanted a number for general purpose use.  But the 
pool could have been greater than "one" in size.)

The dynamic in the development process is this.  (Assuming the goal 
is to get something on the standards track.)  First you want initial 
development you need to plug in a number.  You then need to produce a 
document to get the idea out.  Following this you want there to be 
some wide spread experimentation, which often borders on initial 
deployment.  With this you are prepared for standards vetting and 
then initial deployment.

The snag in this process is that your experimental deployment will 
use value 243 but IANA will give you the value 93.  You then need to 
uproot all the early adopters.  This problem is what has driven many 
applications to use the TXT record - in the case when the number in 
question is the RR type.

The difference here is that you are talking about a different 
protocol parameter, one that is more obscure.  But you will have the 
same issue when you do from -draft-" to RFC/PS and then DS.

Another problem is the documentation issue.  Look at SINK.  Yes, 
there's no RFC because the WG lost it's will to finish off the 
experiment.  On the one hand, we have the number burned into the 
registry and a way to find information about SINK.  Yes, it says 
"Eastlake" and if you know him, you can reach him.  You can also 
search for the draft in many repositories, now even the IETF has one.

If SINK had used an experimental value, you couldn't even do that. 
You might tcpdump and see something using value 243 - but until you 
fingerprinted the source IP address you might not be able tell if 
that was Jelte's bad idea of 2009 or Blacka's bad idea of 2003 (or 
even Jelte's bad idead of 2010, 2011, ...).  Reused numbers make it 
hard to do a text search for "what's happening?"

(Recall the question of "where are all the A6 queries coming from?" 
asked in 2007.  Many of knew right away - BIND - because A6 was a 
specific allocation, fully documented, moved to experimental and 
recognized as a truly had idea by all sane people.  I said "sane.")

The only place that allocating numbers for "private use" that has 
worked is in IPv4 because we have NAT.  (Which everyone "hates" to 
some extent.)  I know there's a call for them in IPv6 because we are 
used to them in IP address management.  Reusable numbers work in IP 
because we control them with the routing system, we don't have a 
similar scoping mechanism available for an application protocol.

I wish that I could be more optimistic about this effort.  I wanted 
to do it once too (for the KEY RR).  But it never seems to work.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

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