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

Andrew Sullivan <ajs@shinkuro.com> Wed, 09 March 2011 19:42 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 6B2493A6A74 for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 11:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level:
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 1fK0GdagW7EG for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 11:42:58 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7C6B53A6967 for <dnsext@ietf.org>; Wed, 9 Mar 2011 11:42:58 -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 068F11ECB408; Wed, 9 Mar 2011 19:44:13 +0000 (UTC)
Date: Wed, 9 Mar 2011 14:44:12 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Message-ID: <20110309194411.GG32629@shinkuro.com>
References: <20110218213453.GB96163@registro.br> <AANLkTi=gfTHvyBrBJhZ4TQhq6xumFuFZuyP-JgSOyZOK@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTi=gfTHvyBrBJhZ4TQhq6xumFuFZuyP-JgSOyZOK@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Ben Laurie <benl@google.com>, Rob Stradling <rob.stradling@comodo.com>, 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: Wed, 09 Mar 2011 19:42:59 -0000

Hi,

With my administrative hat on, I just want to clear up some details.

On Wed, Mar 09, 2011 at 01:33:51PM -0500, Phillip Hallam-Baker wrote:

> In particular we removed a feature from the previous version of the
> specification that allowed a single CAA RR to contain a list of property
> entries. That was considered to be confusing

Is that a change to the definition of the RR?  I.e. is there a
difference between the RRTYPE in the original template and the one in
the latest draft?  If so, it's strictly speaking a new RRTYPE request
and it needs a different template.  The RRTYPE code that you get is
for the particular definition.  There isn't a mechanism so far to get
a number and then be able to change the RRTYPE substantively, because
the idea is that the typecode could be baked into software all over
the place.

> I will make these corrections to the editing copy of the draft.

It would be good, actually, if you could post an update.  The review
requirements include these criteria for rejection:

   1. Was documented in a manner that was not sufficiently clear to
      evaluate or implement.

   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.)

The block diagram in particular would be helpful.
 
> This does not change the intended semantics of the proposal.

The Expert isn't reviewing the semantics of the protocol, so that
doesn't matter.  The expert is simply reviewing whether the RRTYPE
assignment meets the criteria for assignment.  These are pretty broad,
but the filters are important for interoperability and therefore we
need to follow them stringently.  It would help, of course, if I also
followed the procedures stringently and ensured the reviews got done
on time.  I'm not trying to be super bureaucratic here.  But if
there's a change to the RRTYPE as requested, it's important to know
that.

Thanks,

A

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