Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...

Thierry Moreau <thierry.moreau@connotech.com> Thu, 18 April 2013 18:41 UTC

Return-Path: <thierry.moreau@connotech.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16F21F90B4 for <dnsext@ietfa.amsl.com>; Thu, 18 Apr 2013 11:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 plJ+KpeXou3V for <dnsext@ietfa.amsl.com>; Thu, 18 Apr 2013 11:41:29 -0700 (PDT)
Received: from mail.connotech.com (connotech.com [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 356BE21F8D5F for <dnsext@ietf.org>; Thu, 18 Apr 2013 11:41:29 -0700 (PDT)
Received: from [192.168.1.200] (PORTABLE-THIERRY.CONNOTECH-INTERNAL.COM [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id D084D3178A; Thu, 18 Apr 2013 14:41:28 -0400 (EDT)
Message-ID: <51703E58.90300@connotech.com>
Date: Thu, 18 Apr 2013 14:41:28 -0400
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20090608)
MIME-Version: 1.0
To: Donald Eastlake <d3e3e3@gmail.com>
References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> <456792BA-A987-4CAF-968D-EFD9261ECD49@hopcount.ca> <516C2693.2050506@dougbarton.us> <BB4CD5BA-B193-485D-AC54-8E36EC6E4603@hopcount.ca> <516FF953.1010108@connotech.com> <F78E3256-2576-45E7-97B0-F570135BE08E@hopcount.ca> <CAF4+nEGH7s2wEhfuHP0EjQxp1yKaK_2AtX971S5wAaUO8cALfQ@mail.gmail.com>
In-Reply-To: <CAF4+nEGH7s2wEhfuHP0EjQxp1yKaK_2AtX971S5wAaUO8cALfQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF DNSEXT WG <dnsext@ietf.org>
Subject: Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 18 Apr 2013 18:41:30 -0000

Donald Eastlake wrote:
> Hi Thierry,
> 
> Calling anything but April 1st RFCs a "submarine RFC" is pretty silly.
> (April 1st RFCs really do appear with no warning.)
> 

I stand corrected on this one, with the following nuance: while IETF 
processes are eminently transparent and public, they remain obscure and 
complex, at least at the detailed level, for anyone not directly involved.

I stand corrected because IANA web pages indeed refers to the I-D once 
approved and until the RFC is published (but still, once the RFC is 
published, the date of I-D approval disappears from the IANA web pages 
... so a hindsight understanding of IANA motivation for a protocol 
assignment between I-D approval and RFC publication is harder).

> They are all internet-drafts first and publicly available there even
> before they are listed in the RFC Edtior's queue for, usually, a
> couple of months, while going through the editing process. And, in the
> case of a WG document like rfc6195bis, there is notice and discussion
> in the working group, the IETF Last Call, the IESG process tracked in
> the datatracker, etc.
> 
> The IESG has the standards setting and BCP approval authority in the
> IETF. It has always been the case that, unless perhaps there is some
> special provision in the document, drafts take effect on the final
> approval by the IESG, that is, at the time they are transferred to the
> RFC Editor, not when the RFC issues.
> 

I never figured out how to train myself about BCP. I got bored of IETF 
process before I could. So what about others not directly involved?

> RFC Editor's queue is here, which is linked off the RFC Editor home page:
> http://www.rfc-editor.org/queue2.html
> RFC publication can be held up for a variety of reasons. The oldest
> document currently in the queue was placed there 2012-02-21, almost 14
> months ago.
> 
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com
> 
> 
> On Thu, Apr 18, 2013 at 10:16 AM, Joe Abley <jabley@hopcount.ca> wrote:
>> On 2013-04-18, at 09:46, Thierry Moreau <thierry.moreau@connotech.com> wrote:
>>
>>> Joe Abley wrote:
>>>> On 2013-04-15, at 12:10, Doug Barton <dougb@dougbarton.us> wrote:
>>>>> It's also not clear why IANA has already assigned code points for this (as described in your text).
>>>> Because the expert review passed, and IANA was following the required procedure, I think.
>>> [reviewing the discussion from a process perspective -- what is the root cause of the controversy?]
>>>
>>> It appears that the bar for RR type allocation is lower than for an informational RFC.
>> The RRType application registry's bar is "expert review". The bar for publication of an informational RFC depends on what stream you follow, whether it's a working group document, etc. It's not clear to me that one bar is obviously lower; they're just different.
>>
>>> To which extent should the IESG lower the bar for a specific I-D on the ground that it acquired an RR type?
>> I'm not sure that it should (nor that anybody has suggested it should, or would).
>>
>>> Incidentally:
>>>
>>> Process-wise, we could be in front of a "submarine RFC" case: IANA (or the expert?) would have followed the RFC6895 procedures before it was published.
>> As I understand it, the directions in draft-ietf-dnsext-rfc6195bis-05 were followed by the IANA once that document was approved by the IESG. It looks like that happened in December last year. The document emerged from the RFC editor queue as RFC6895 two days ago.
>>
>> It doesn't seem unreasonable that "IESG approval" is the trigger here, rather than "RFC published".
>>
>>> It bugs me that the IANA allocation process uses a mailing list a) not listed in the IANA web pages, and b) (I guess) subject to the IETF IPR disclosure policy by virtue of being run under the ietf.org domain.
>> I'm not sure what mailing list you're talking about. Applications for RRTYPE code point assignments are sent to dns-rrtype-applications@ietf.org, which seems to forward to a ticket system at the IANA.
>>
>>> I am not particularly expert in those details, but somehow I care that
>>> 1) stakeholders are created equal, but some are more equal than others (e.g. those aware in advance of the submarine RFC), and
>> I had no particular awareness of the process when I applied for code points for EUI48 and EUI64 -- I just found the relevant registry at www.iana.org and clicked the link above the table. That took me to draft-ietf-dnsext-rfc6195bis-05 which contained instructions; I followed them.
>>
>>> 2) who controls the process controls the outcome.
>> My experience with this application was that the process was efficient, easy to find and easy to understand.
>>
>>
>> Joe
>> _______________________________________________
>> dnsext mailing list
>> dnsext@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsext
> 


-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691