Subject: Re: [manet] DLEP-17: IANA Considerations

From: Rick Taylor <[email-masked]>
Date: Wed, 9 Mar 2016 10:11:55 +0000

Comments inline...

On 24/11/15 16:08, RJ Atkinson wrote:
>
> 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.

Yes, the IANA section needed update, we believe we have this fixed in 
draft-20.  Please double check?

On to the next mail...

Rick