IETF Logo Mail Archive

Re: [dnsext] WGLC: RFC6195bis IANA guidance

"Michael Sheldon" <msheldon@godaddy.com> Fri, 06 July 2012 00:09 UTC

Return-Path: <msheldon@godaddy.com>
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 7923D21F8707 for <dnsext@ietfa.amsl.com>; Thu, 5 Jul 2012 17:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 vW7meW1mtGmx for <dnsext@ietfa.amsl.com>; Thu, 5 Jul 2012 17:09:55 -0700 (PDT)
Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id C0F6121F8705 for <dnsext@ietf.org>; Thu, 5 Jul 2012 17:09:55 -0700 (PDT)
Received: (qmail 11970 invoked from network); 6 Jul 2012 00:10:07 -0000
Received: from unknown (HELO gem-wbe37.prod.mesa1.secureserver.net) (64.202.189.51) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 6 Jul 2012 00:10:07 -0000
Received: (qmail 5181 invoked by uid 99); 6 Jul 2012 00:10:07 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 172.19.38.144
User-Agent: Workspace Webmail 5.6.22
Message-Id: <20120705171005.205a61dff9fc1684c258b274662bb912.6aa0bf2606.wbe@email00.secureserver.net>
From: Michael Sheldon <msheldon@godaddy.com>
To: IETF DNSEXT WG <dnsext@ietf.org>
Date: Thu, 05 Jul 2012 17:10:05 -0700
Mime-Version: 1.0
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 00:09:56 -0000

> From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
> Date: Tue, July 03, 2012 8:05 am
>
> 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?

This is intriguing, though would only be needed by relatively complex
record types...

Still, this would have to be defined as part of the original record
specification, along with the procedures for defining new versions, and
procedures for resolvers, servers and applications when encountering
versions they do not understand/support.

And then again, how many times would this have been useful?

Michael Sheldon
Dev-DNS Services
GoDaddy.com

v2.38.3 | Report a Bug | By Email | System Status