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

[Graham Klyne <[e-mail]>]

Hi Robert,

Yes, I thought I was a bit off-topic.

FWIW, I've planted a link to this discussion of 
https://datatracker.ietf.org/doc/draft-wilde-registries/ at 
https://github.com/dret/I-D/issues/24

#g
--


On 27/01/2016 19:25, Robert Sparks wrote:
> 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
>>
>>
>