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
- Re: [dnsext] [dane] TLSA == RRtype 52 Andrew Sullivan
- Re: [dnsext] [dane] TLSA == RRtype 52 Paul Hoffman
- Re: [dnsext] [dane] TLSA == RRtype 52 Andrew Sullivan
- Re: [dnsext] [dane] TLSA == RRtype 52 Ondřej Surý