Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th
Samuel Weiler <weiler@watson.org> Thu, 10 March 2011 17:07 UTC
Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41AD3A6930; Thu, 10 Mar 2011 09:07:10 -0800 (PST)
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4ACC3A6A3B for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 09:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URPZRUNFr05K for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 09:07:07 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 4F4C63A6930 for <dnsext@ietf.org>; Thu, 10 Mar 2011 09:07:07 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p2AH8MCV083942; Thu, 10 Mar 2011 12:08:22 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p2AH8M7i083939; Thu, 10 Mar 2011 12:08:22 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 10 Mar 2011 12:08:22 -0500
From: Samuel Weiler <weiler@watson.org>
To: Phillip Hallam-Baker <hallam@gmail.com>
In-Reply-To: <AANLkTimtO-UaJDt+RTdyE56TU-7++OPH55dc_9Xbg3VJ@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1103100953450.60284@fledge.watson.org>
References: <20110218213453.GB96163@registro.br> <alpine.BSF.2.00.1103100742001.60284@fledge.watson.org> <AANLkTimtO-UaJDt+RTdyE56TU-7++OPH55dc_9Xbg3VJ@mail.gmail.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1019228496-1299769818=:60284"
Content-ID: <alpine.BSF.2.00.1103101203010.60284@fledge.watson.org>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 10 Mar 2011 12:08:23 -0500 (EST)
Cc: dnsext@ietf.org
Subject: Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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>
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org
> Thats a process issue outside my scope :-) Heh. Indeed. :-) > It might be appropriate to skip the IANA registry for the moment. Resubmit the specificcation with no IANA registry > ("here are the two values") and only create the registry in the RFC. > > That would only change the template, not the draft? ... > I am trying to follow the process as I understand it here and that > requires the template to specify the registries the draft proposes > to create. I'm sensitive to the "we don't want to start over from square one". I also want to be able to point to a firm "here's the definition of the RRTYPE" document. And I'm concerned that your use of the "Expert Review" IANA assignment metric is underspecified in this case. I was suggesting you take the IANA registry bits out of the draft (for now), point to a static-list version of the draft for purposes of RRTYPE assignment, and later create a registry for that field (in a subsequent revision of the i-d, as it gets closer to publication). I suppose that's inconsistent, in some ways, with wanting a static specification, but it highlights my desire to nail down particular version of the i-d which is the definition. Two alternate ideas are below. > Now what may well make more sense as a process would be to have a > two phase scheme in which DNS RR codes are marked 'reserved' in > response to the expert review and the final allocation is performed > when the RFC is issued. This is effectively what has happened with > Stuart Cheshire's Bonjour scheme. > > But that is not the process we have. You can still do that: 5395 specifically recognizes that RFC can allocate RRTYPES (with no template), including using the RFC420 early allocation process. It sounds like that might be appropriate here, since you plan to publish as an RFC -- skip the template and ask for an early allocation. Another idea: change the IANA assignment metric to one of the more thoroughly defined ones like "First Come First Served" or "RFC Required". Those get you away from needing to tell the expert what to look for, though with First Come First Served you still should put restrictions on the tag field (max length 15 and only numbers and lowercase letters, consistent with section 3.1 of the draft). You can easily change that assignment metric later. > Which brings us to the discussion on the list yesterday: the template should really be citing a particular version of the > spec. It hardly seems fair to ask the expert to approve an RRTYPE based on a reference to a changing document. > > I think that is unhelpful. I think of it more from the "let's make sure the record is clear" perspective. In two years, how will I know which version of the document is the one that defined this RRTYPE? -- Sam
_______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
- [dnsext] CAA RRTYPE review - Comments period end … Frederico A C Neves
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - Comments period … Samuel Weiler
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Samuel Weiler
- Re: [dnsext] CAA RRTYPE review - Comments period … Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - Comments period … Andrew Sullivan
- [dnsext] [IANA #434639] Re: CAA RRTYPE review - C… Amanda Baber via RT
- Re: [dnsext] CAA RRTYPE review - Comments period … Paul Hoffman
- Re: [dnsext] [IANA #434639] Re: CAA RRTYPE review… Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Frederico A C Neves
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Andrew Sullivan
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Phillip Hallam-Baker
- Re: [dnsext] CAA RRTYPE review - result [IANA #43… Paul Wouters