Re: Last Call: <draft-leiba-cotton-iana-5226bis-08.txt> (Guidelines for

Hi,

I have several questions and a concern regarding this document:
>    This document defines the designated expert mechanism with respect to
>    documents in the IETF stream only.  Documents in other streams may
>    only use a registration policy that requires a designated expert if
>    those streams (or those documents) specify how designated experts are
>    appointed and managed.  What is described below, with management by
>    the IESG, is only appropriate for the IETF stream.
Can you explain what is meant by this paragraph, and could you provide
an example where this document does NOT apply?

>    o  The designated expert is not required to personally bear the
>       burden of evaluating and deciding all requests, but acts as a
>       shepherd for the request, enlisting the help of others as
>       appropriate.  In the case that a request is denied, and rejecting
>       the request is likely to be controversial, the expert should have
>       the support of other subject matter experts.  That is, the expert
>       must be able to defend a decision to the community as a whole.
The penultimate sentence of the paragraph seems to impose a new step to
reject a request.  I'd like to understand what led to this text being
inserted.  As the IESG been inundated with appeals of technical expert
decisions?  I am concerned because if we increase the burden on experts
who are volunteers, I'd point out, people may find that the effort isn't
worth the results to continue.

Thanks,

Eliot


On 10/2/14, 3:47 PM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Guidelines for Writing an IANA Considerations Section in RFCs'
>   <draft-leiba-cotton-iana-5226bis-08.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf(_at_)ietf(_dot_)org mailing lists by 2014-10-30. Exceptionally, comments 
> may be
> sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    Many protocols make use of points of extensibility that use constants
>    to identify various protocol parameters.  To ensure that the values
>    used in these fields do not have conflicting uses, and to promote
>    interoperability, their allocation is often coordinated by a central
>    authority.  For IETF protocols, that role is filled by the Internet
>    Assigned Numbers Authority (IANA).
>
>    To make assignments in a given namespace prudently, IANA needs
>    guidance describing the conditions under which new values should be
>    assigned, as well as when and how modifications to existing values
>    can be made.  This document defines a framework for the documentation
>    of these guidelines by specification authors, in order to assure that
>    the guidance given to IANA is clear and addresses the various issues
>    that are likely in the operation of a registry.
>
>    This is the third edition, and obsoletes RFC 5226.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.

signature.asc
Description: OpenPGP digital signature