Hi Graham -
You raise some good points to discuss, but this particular document
isn't the place to capture the results of the conversation.
There have been a few other comments on ietf general related to the
expert review infrastructure in particular that would be good to pull
into the discussion. While your primary suggestion crosses streams, I
think it would be good to have the IESG staring at this closely too.
RjS
On 12/16/15 6:00 PM, Graham Klyne wrote:
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@xxxxxxx.
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