Re: Last Call: <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

John C Klensin <john-ietf@jck.com> Fri, 21 June 2013 01:48 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61F311E8146 for <ietf@ietfa.amsl.com>; Thu, 20 Jun 2013 18:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Level:
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 Fxr3Ec7lrKMW for <ietf@ietfa.amsl.com>; Thu, 20 Jun 2013 18:48:38 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D759321E80DF for <ietf@ietf.org>; Thu, 20 Jun 2013 18:48:38 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1UpqSq-0005gT-QQ; Thu, 20 Jun 2013 21:48:36 -0400
Date: Thu, 20 Jun 2013 21:48:31 -0400
From: John C Klensin <john-ietf@jck.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Subject: Re: Last Call: <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Message-ID: <5D74490A7A2EBB54CBD1DD24@JcK-HP8200.jck.com>
In-Reply-To: <20130620163611.GB41900@mx1.yitter.info>
References: <20130520134442.30045.33596.idtracker@ietfa.amsl.com> <51C1B235.6020507@bogus.com> <E8415CD2-AC5F-47CF-B740-65C45B181AC8@ogud.com> <FA4B2D6DB820F27675F8E13B@JcK-HP8200.jck.com> <20130620163611.GB41900@mx1.yitter.info>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2013 01:48:44 -0000

--On Thursday, June 20, 2013 12:36 -0400 Andrew Sullivan
<ajs@anvilwalrusden.com> wrote:

> On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote:
>  
>> So some review of the DNSEXT-specified procedures and
>> expectations may be in order.
>...
> But more generally, as a practical matter it is better that
> people register their stuff with us than that they don't.  We
> have, in the wild, a used EDNS0 option code that is all over
> the Internet.  It is undocumented, and the code point isn't
> actually registered.  That state of affairs is surely worse
> than that the IETF didn't get to provide good advice to
> authors.  DNSEXT already tried to be the DNS cops, and has
> failed miserably, partly because of the usual get-off-my-lawn
> crowd and partly because people unfamiliar with the IETF find
> its procedures a little arcane.
> 
> My view is that we need to be more pragmatic.

Andrew,

Just to be clear, I completely agree.  I thought that should
have been clear from the context of my note (context that you
omitted above).  I think that what I have referred to as the
lightweight registration procedure is just fine.  What I have
objected to since the first time a Last Call on the present
document was initiated is any assertion that, because something
is registered, it is entitled to be documented in the RFC
Series.   I object even more strongly to any implication that
such a registered RRTYPE should be accepted as a Standards Track
document without any further review because it is registered
already.

I thought that issue had been settled for this document by
reclassifying its intended status to Informational and
clarifying the relationship of the RRTYPEs to other
consideration, particularly privacy ones.  IMO, that
clarification along makes it worth publishing as an RFC, but the
notion of entitlement was, I thought, put to rest.

Consequently, I was mildly astonished when Olafur's comment
(which included the information that he is co-chair of DNSEXT)
included "...we (DNS community) want to encore [sic] that any
such allocations be published as RFC's for future references".  

So, once again and in short sentences:

(1) The present registration procedure does nothing to ensure
any such thing.

(2) There is nothing else in either IETF or RFC Editor
procedures that ensures RFC publication.  If a document
describing an already-registered RRTYPE is submitted and some AD
wants to sponsor it for publication as an individual submission
and puts it into a Last Call on that basis, the community may
pick at it, insist on changes, or even reach consensus that it
should not be published.

(3) I think the above is fine.  If someone (else) thinks that
RFC publication should be "ensured" for any RRTYPE allocation,
then they need to persuade whomever needs to be persuaded to
modify the registration procedure.   I would, personally, oppose
that change if it eliminated the possibility of quick,
lightweight, registrations but my opinion probably doesn't count
for much relative to the "DNS community" for which Olafur and/or
you are speaking.

best,
    john