IANA considerations and expert review across different streams (was Re: [IAB] Call for comment: <draft-iab-rfc5741bis-01> (On RFC Streams, Headers, and Boilerplates))

[Robert Sparks <[e-mail]>]

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
>> [e-mail].
>>
>>
>> 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
>
>