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

Andrew Sullivan <ajs@shinkuro.com> Thu, 10 March 2011 20:06 UTC

Return-Path: <ajs@shinkuro.com>
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 AA1AF3A67FF for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 12:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level:
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 KMAhpbGNGTdw for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 12:06:33 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9F3373A6941 for <dnsext@ietf.org>; Thu, 10 Mar 2011 12:06:33 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A70F01ECB408 for <dnsext@ietf.org>; Thu, 10 Mar 2011 20:07:50 +0000 (UTC)
Date: Thu, 10 Mar 2011 15:07:48 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsext@ietf.org
Message-ID: <20110310200748.GY57756@shinkuro.com>
References: <20110218213453.GB96163@registro.br> <alpine.BSF.2.00.1103100742001.60284@fledge.watson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.00.1103100742001.60284@fledge.watson.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
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 20:06:34 -0000

Dear colleagues,

I write as the locally-appointed pointy-hair on this subject.  I am
not the appointed Expert, please note.

On Thu, Mar 10, 2011 at 07:55:08AM -0500, Samuel Weiler wrote:
>
> Is it really appropriate to allow a template to create IANA registries?  

The template does not actually leave open the possibility of creating
an entirely new registry, but it does permit "the creation of a new
IANA sub-registry in DNS Parameters?"  I've always found this a little
odd, but RFC 5395 does not list this as a reason to reject the
application.  RFC 5395, on my reading, defaults to permissive: as long
as section 3.1.1 criteria 1 and 2 are met, then the application should
go ahead so long as it does not meet any of the criteria under section
3.1.2.  Therefore, I see no reason that subregistries to DNS
Parameters can not be created along with an RRTYPE.

The registration rules are what make this a little funny.  But the
template does not require us to specify the registration rules for the
subregistry, and RFC 5395 is similarly silent.  I think any I-D that
actually specifies the RRTYPE and its use should, in the end, also
contain rules for the registration in the subregistry.  But I am not
at all sure that the registry's rules need to be specified at its
creation.  (I wouldn't be surprised to learn I am wrong about this; if
so, I'd like a reference to the rules.)

> It might be appropriate to skip the IANA registry for the moment.  

If the RRTYPE requires a subregistry, then the subregistry is not
optional; that would make the template incomplete.

> Which brings us to the discussion on the list yesterday: the template  
> should really be citing a particular version of the spec.

I don't believe it should, and I don't think that would be desirable.

There are two reasons for that.

First, the template says this:

   E.    Description of the proposed RR type.
         This description can be provided in-line in the template, as an
         attachment, or with a publicly available URL:

The publicly-available URL might well track changes to the use of the
RRTYPE.  As long as the use does not violate any of the rules, even if
the use changes slightly, that appears to be allowable.  

Moreover, section 3.1.2 of RFC 5395 appears explicitly to allow
changing documentation:

   3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete.
      (Additional documentation can be provided during the public
      comment period or by the Expert.)

Finally, the template has room for the case where an existing RRTYPE
(presumably, one assigned early on in the review process) is altered:

   B.    Submission Type:
         [ ] New RRTYPE
         [ ] Modification to existing RRTYPE

This suggests that the WG was prepared for the possibility that
RRTYPEs would change slightly in the time between initial conception
and assignment, and between assignment and final publication.  Small
communities of users of an RRTYPE can presumably be expected to
tolerate incompatible changes shortly after assignment, when all the
implementations in the world are still being used by the developers
and nobody else.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.