Re: [dnsext] CAA RRTYPE review - Comments period end Mar 11th

Samuel Weiler <weiler@watson.org> Thu, 10 March 2011 17:07 UTC

Return-Path: <weiler@watson.org>
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>
X-List-Received-Date: Thu, 10 Mar 2011 17:07:09 -0000

> 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