Re: [dnsext] WGLC: RFC6195bis IANA guidance

Mark Andrews <marka@isc.org> Fri, 06 July 2012 09:38 UTC

Return-Path: <marka@isc.org>
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 9C90621F86B2 for <dnsext@ietfa.amsl.com>; Fri, 6 Jul 2012 02:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 w-5L+eQbuq9F for <dnsext@ietfa.amsl.com>; Fri, 6 Jul 2012 02:38:04 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0921F864D for <dnsext@ietf.org>; Fri, 6 Jul 2012 02:38:03 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6211BC95E1; Fri, 6 Jul 2012 09:38:14 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (CPE-123-211-135-142.lnse3.woo.bigpond.net.au [123.211.135.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CAF73216C36; Fri, 6 Jul 2012 09:37:54 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id AED242238832; Fri, 6 Jul 2012 18:59:16 +1000 (EST)
To: Paul Hoffman <paul.hoffman@vpnc.org>
From: Mark Andrews <marka@isc.org>
References: <20120613090016.205a61dff9fc1684c258b274662bb912.d2ce8b95d9.wbe@email00.secureserver.net> <CAF4+nEGbZavii4p_km2kRik-5B2RB19wJ2TFZJ-tSbX-x=Nh6A@mail.gmail.com> <CAF4+nEHdtq2dRknB8NEasfz7THUOfpPaE7Qr189CjQpZVt5D2w@mail.gmail.com> <20120703141331.45D4D222DC10@drugs.dv.isc.org> <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org>
In-reply-to: Your message of "Tue, 03 Jul 2012 07:45:50 MST." <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org>
Date: Fri, 06 Jul 2012 18:59:16 +1000
Message-Id: <20120706085916.AED242238832@drugs.dv.isc.org>
Cc: IETF DNSEXT WG <dnsext@ietf.org>
Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance
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>
X-List-Received-Date: Fri, 06 Jul 2012 09:38:04 -0000

In message <6AB4DF76-54EE-49A6-8F3E-BF1FA7782711@vpnc.org>, Paul Hoffman writes:
> On Jul 3, 2012, at 7:13 AM, Mark Andrews wrote:
> 
> >>>   RRTYPE assignments need to say something about the rdata format
> >>>   no longer being subject to change.  Its not for reserving a code
> >>>   point as it will be coded into implementations.
> >=20
> > DANE thought that they had a code point that they could change the
> > internal structure about at will by going through the allocation
> > process.  They needed to be disavowed of this notion.  This should
> > not happen again.
> 
> Mark's sneering is one way to look at it.

For a expert to be able to evaluate a RR type definition it needs
to be stable.  No expert can say a RR type definintion can be said
to be safe / good if it is still subject to change.

> Another is that, with an =
> RRtype in a mature draft that labelled as TBD, implementers will just =
> pick one and then eventually squat on it, screwing up both the registry =
> and implementations.

Then pick a private type for testing.  Been there, done that.  It is
not impossible to do.

> Standards-track protocols can be changed all the way through IESG =
> review. Those changes could in fact change the internal structure of the =
> data covered in an RRtype. This leaves exactly two choices:

And that ends up with a total review of the impact of the new
structure has on the old implementations.  This level of review
doesn't happen between I-D revisions.

> - Force Internet-Drafts to keep their RRtype as TBD all the way until =
> the IESG passes the Internet-Draft to the RFC Editor
> 
> - Allow WGs and document authors to request RRtype assignment earlier in =
> the process and know that there might be a change based on technical =
> review of the document
> 
> Pick one.
> 
> --Paul Hoffman=
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org