Re: [dnsext] [dane] TLSA == RRtype 52

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 16 April 2012 19:59 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811F21F86E8; Mon, 16 Apr 2012 12:59:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334606379; bh=J+F/ZQ9Bb09AKUL0sLLtgVY5Pq3Su2YoyAHu6vmnk1s=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=gJiCR7ipSWPWC4q2HmY9cbx8I41ULi+ZQebvBXKn0wfyW0TZ9+q4cvtm6YlPrW4VQ DCraGN0mEnUIeIvsHKCz8EytUzGEgzyyadYXriyD52c2sAN0M1hiweRtAqfIG93lzT yvInQpIK9j+NPelYfGy7tAlO4lqdBin1u/Q+uilM=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C221921F86E8; Mon, 16 Apr 2012 12:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn46Qw5XJqkO; Mon, 16 Apr 2012 12:59:37 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7221F86E4; Mon, 16 Apr 2012 12:59:37 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 563481ECB420; Mon, 16 Apr 2012 19:59:36 +0000 (UTC)
Date: Mon, 16 Apr 2012 15:59:34 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dane@ietf.org, dnsext@ietf.org
Message-ID: <20120416195934.GM49880@mail.yitter.info>
References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> <4F8C71E6.1010103@ogud.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F8C71E6.1010103@ogud.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dnsext] [dane] TLSA == RRtype 52
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

This is really a discussion about an issue for the DNSEXT WG, so it's
cc:d there.  Follow ups should go there, too, unless they're linked
tightly to the DANE issue.  I didn't adjust the Followup header
because in my experience that never works.

On Mon, Apr 16, 2012 at 03:24:22PM -0400, Olafur Gudmundsson wrote:
> But the application in this case referenced a particular version of an
> Internet draft:

Yes.  This is why some people have objected to the difficulty of
getting the approved templates.  The template as in the application is
not necessarily what was approved.  I think in this case it is, but as
we see the registry does not actually preserve the link.

> If there are changes in the registries that are created by the ID
> that is fine.
> Type codes are cheap, interoperability problems are not.

Yes.  Which is rather a good reason to hesitate to ship code that
doesn't have a stable refernence in the registry, if you ask me.

> There is code range for experimentations, see RFC6195 section 2.3
> 	   0x0F01 - 0x0FFF     Private Use

Yes, I'm perfectly aware of that.  The complaint has been that people
want to be able to ship things with what they regard as minor
differences without having to go through the DNS mafia again.  Like it
or not (I'm in the "not" camp), people are engineering around our
community's intransigence.

> Andrew I hate to correct you, the whole point of early allocation
> was to avoid having to publish an standards track RFC in order to
> get
> an RR type code.

That could be better achieved by "specification required".  Expert
review allows us to allocate a type code without any guarantee that
the wire format will remain stable.  There is exactly one way to
guarantee that such a wire format will remain stable, and that is to
publish something in an archival series.  We have a way to do that:
publish an RFC.  Requiring conformance with RRTYPE application
templates or anything else is nonsense, because the references aren't
stable.  This is in fact a much more serious example of the same fight
we had when we tried to be clever with the registry in the
registry-fixes attempt some time ago.  (In that case, I happened to
think we were right, but the objection rested on the same foundation:
if you want a stable reference, put it in an RFC.)

> what is wrong with using 0xf?? values for that ?
> 
> all you need to do is to send a email to the wg mailing list saying
> "I want to do an experiment and we will use code X here is my format."
> the private RRtype either contains version number or you roll the
> code each time there are wire format changes. In this case only
> consenting implementations are at risk.

Nothing, of course.  I have no idea why people even want RRTYPE
assignments prior to publishing an RFC with the specification, but
people do.

> If a simple building block like DNS record format needs to change
> during IESG review, the whole WG effort is suspect and it should be
> sent to back to the drawing board.

I fully agree.  But it is one thing to say, "This sure hadn't better
change.  If it does, something is really wrong," and quite another to
say, "This can't possibly change."

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext