IETF Logo Mail Archive

Re: [dnsext] WGLC: RFC6195bis IANA guidance

Nicholas Weaver <nweaver@icsi.berkeley.edu> Tue, 03 July 2012 15:05 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 05D5B21F8848; Tue, 3 Jul 2012 08:05:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341327931; bh=fY8DNpQ4HlLpQWQhQDOvgRGfgJfIhDyVauYS/OKX3Vs=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Y991zuzUFwQ47Xp6TgLklwCub3ulmLjUF8k3moL5MRV62Ykr5Ae4zv9A/AN8musNB AJ3shcqCttprZczkP0WzwxcmkBibKGSaK20nJ4mNUG/yzaJj8AiNuJEvuhHV5FD790 GCP4qYCoW8ovxsD+VPEjUYn870DK7DfSI5Kb1ajQ=
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 875DA21F86DE for <dnsext@ietfa.amsl.com>; Tue, 3 Jul 2012 08:05:29 -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=[AWL=0.000, 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 5DictPgTCWcr for <dnsext@ietfa.amsl.com>; Tue, 3 Jul 2012 08:05:29 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id E859221F8848 for <dnsext@ietf.org>; Tue, 3 Jul 2012 08:05:28 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id ECE762C4003; Tue, 3 Jul 2012 08:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3OAzDaAx9gtP; Tue, 3 Jul 2012 08:05:36 -0700 (PDT)
Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id AA28A2C4002; Tue, 3 Jul 2012 08:05:36 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <20120703141331.45D4D222DC10@drugs.dv.isc.org>
Date: Tue, 03 Jul 2012 08:05:36 -0700
Message-Id: <09F9497E-099B-4880-8E17-55A63633D775@icsi.berkeley.edu>
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>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1278)
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On Jul 3, 2012, at 7:13 AM, Mark Andrews wrote:
>> I'm not quite certain what you mean above. That the RDATA format
>> approved as part of the RRTYPE assignment process can never be changed
>> later? Seems reasonable that it can't be changed unilaterally. But I
>> don't see why you shouldn't be able to change it by going through the
>> process again.
> 
> Because once you have code in the field that knows the internal
> structure of a RR changing that structure breaks those implementations
> that have implemented the RR. 

So by this logic, why not just advise every future RTYPE requests include, as the first byte, a version number field, allowing all future RTYPE requests to enable updates without needing to register a new RTYPE?


And DANE can get this already:  Any changes to the certificate associate data should have a new usage number, and usage number 255 means that the first octet of the otherwise opaque certificate association data is the extended usage type.


Voila, problem solved.

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

v2.23.0 | Report a Bug | By Email