Subject: [manet] DLEP-17: IANA Considerations

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 11:08:31 -0500

The IANA Considerations in Section 12 is much better,
but still does not seem to be compliant with RFC-5226.

For example, RFC-5226 Section 4.1 language ought to be
used when describing the allocation policy (e.g.,
Hierarchical Allocation, First Come First Served, 
Expert Review, Specification Required, RFC Required,
IETF Review, Standards Action, IESG Approval).

It is permitted to have more than 1 authorized allocation 
policy allowed for a given registry created in an IETF RFC.  
For example, it is common to have “Expert Review, IETF
Review, Standards Action, or IESG Approval” all be allowed
(concurrently) as ways for a new registry allocation to be 
approved.  As an example, specifying “Expert Review” alone 
would mean that the DLEP WG publishing an an IETF Standards Track 
DLEP Extension would NOT be sufficient to allocate a code point 
— which would be both a very odd outcome and very odd registry
management approach.

Separately, the goal of this section should be that when
the IANA staff read the IANA Considerations section of
the draft (without reading the rest of the draft) immediately
know exactly what they need to do to create and document
any new registries — and to update any existing registries
with new entries.  The current section 12.2 is not close 
to being sufficient in this regard.

If folks want help getting this section into correct form,
I’m happy to help.

Yours,

Ran