Re: Call for comment: <draft-iab-rfc5741bis-01> (On RFC Streams, Headers, and Boilerplates)

Graham Klyne <gk@ninebynine.org> Thu, 17 December 2015 00:00 UTC

Return-Path: <gk@ninebynine.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0083A1A9155; Wed, 16 Dec 2015 16:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUVjSyndE78Y; Wed, 16 Dec 2015 16:00:18 -0800 (PST)
Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 517321A8AF1; Wed, 16 Dec 2015 16:00:18 -0800 (PST)
Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1a9LzU-0002D5-hv; Thu, 17 Dec 2015 00:00:16 +0000
Received: from gklyne38.plus.com ([81.174.129.24] helo=conina.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1a9LzU-0004JY-Hl; Thu, 17 Dec 2015 00:00:16 +0000
Message-ID: <5671FB0F.9010105@ninebynine.org>
Date: Thu, 17 Dec 2015 00:00:15 +0000
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: ietf@ietf.org, iab@iab.org
Subject: Re: Call for comment: <draft-iab-rfc5741bis-01> (On RFC Streams, Headers, and Boilerplates)
References: <20151216174741.5946.14928.idtracker@ietfa.amsl.com>
In-Reply-To: <20151216174741.5946.14928.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dUgVUzztpyemPhwU2UnUF49KIp4>
X-Mailman-Approved-At: Thu, 17 Dec 2015 09:00:12 -0800
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Dec 2015 00:00:22 -0000

On 16/12/2015 17:47, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-rfc5741bis-01.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection here:
> https://datatracker.ietf.org/doc/draft-iab-rfc5741bis/
>
> The Call for Comment will last until 2016-01-13. Please send comments to
> iab@iab.org.
>
>
> Abstract
>
>     RFC documents contain a number of fixed elements such as the title
>     page header, standard boilerplates and copyright/IPR statements.
>     This document describes them and introduces some updates to reflect
>     current usage and requirements of RFC publication.  In particular,
>     this updated structure is intended to communicate clearly the source
>     of RFC creation and review.  This document obsoletes RFC 5741, moving
>     detailed content to an IAB web page and preparing for more flexible
>     output formats.

I welcome this attempt to clarify the status of RFCs that are published by 
differing routes.  The point of my comment here is to ask if it might be 
appropriate to extend the clarification provided to include the effect of IANA 
considerations actions in RFCs from various streams (that request registrations 
that are commonly associated with standards actions).

My comments here derive from reflection of my role as designated IANA reviewer 
for URI-scheme and message header field name registries, administered under 
guidance of [RFC7595] and [RFC3864] respectively.

Both the IANA URI scheme registry [1] and the message header registry [2] have 
allowance for *provisional* and *permanent* registrations, with the intent that 
provisional registrations are permitted with low overhead so that useful 
information about work in progress is easily made available at a well-known 
location, and permanent registrations are subject to a degree of review and 
practice that developers should feel comfortable to use them in their 
implementation of Internet-facing applications.

There have been a small number of cases in which an ISE RFC publication has 
requested a permanent registration (where the small number here is 2 or 3).

In at least one case, I felt that the lack of IETF review and/or widespread 
implementation meant that permanent registration was not appropriate, but the 
specifics of the guiding RFC did not make this an obviously correct decision, 
and I felt I needed to request wider support for my view.

In at least one other case, despite the lack of formal review, I felt the 
process followed, discussion that had taken place and apparent scope of 
implementation meant that request for permanent registration was appropriate, 
but again I felt the need to solicit support for this view.

My general concern here is that the status of IANA actions in ISE stream 
publications is sometimes unclear, and use of the ISE track for RFC publication 
might be used as an end run-around the expected review process that is commonly 
associated with some registrations.  In hindsight, [RFC3864] (section 2.1) 
should explicitly indicate IETF-stream informational RFC publication, but at the 
time this was written, IIRC, independent publications were still usually 
last-called in the IETF.

You might reasonably say that the purpose of expert review is to deal with edge 
cases like the ones I mention, and I'm OK with that.  But I'm also aware that it 
is important for decisions and processes to be as transparent as possible:  if 
review decisions can appear to be arbitrary or unexpected then registrations may 
be discouraged and the purpose of the registries undermined.

Thanks.

#g
--

[1] http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

[2] http://www.iana.org/assignments/message-headers/message-headers.xhtml

[RFC7595] http://tools.ietf.org/html/rfc7595

[RFC3864] http://tools.ietf.org/html/rfc3864