Re: Last Call: <draft-leiba-cotton-iana-5226bis-08.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

[Eliot Lear <lear@xxxxxxxxx>]

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@xxxxxxxx mailing lists by 2014-10-30. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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.

Attachment: signature.asc
Description: OpenPGP digital signature