Subject: [manet] DLEP-16: IANA Considerations - Mechanics

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Aug 2015 16:30:20 -0400

All, 

 This note is focused on the mechanics of the IANA Considerations section,
rather than about WG choices about the actual contents of the to-be-created
DLEP IANA registries. 

By the way, the correct IANA term is “registry” rather than “repository”.

These issues were reported earlier but seem to have been 
overlooked.  They need to be fixed before the document
leaves the MANET WG.

1) Basic contents for “IANA Considerations” 

 The basic task is to specify each new registry, specify allocation 
policies, and specify initial values arising from this document (if any). 

 All of Section 12 needs to comply with RFC-5226 and should cite RFC-5226 
when using reserved phrases or reserved words defined within RFC-5226. 
I do not believe that DLEP-16 is fully compliant with RFC-5226. 

A) Each new registry deserves its own sub-section, rather than all
   being lumped together in Section 12.1. 

 Each new registry needs to have the registry name specified. It is helpful 
(and I believe also customary) to include the protocol as the first term 
of the formal name of the registry to help users of the IANA registry 
find the then-current assigned values. This also makes crystal clear 
that a given registry is associated with DLEP rather than some other 
protocol. 

Example edit: 

   "12.3 DLEP Signal Type and Message Type Registry” 
 
    DLEP Signals and DLEP Messages share a common option Type number space. 
    This registry defines all of the DLEP Signal Type and DLEP Message Type
    numbers.” 

B) Initial values allocated by this document need to be specified within 
   each newly created IANA registry sub-section. 

It is not kind to make the IANA folks hunt all over a document to find 
 initial registry values. 

Example edit for Section 12.3: 
   (Insert/copy current Table 1 into Section 12.3.) 

C) Each new registry needs to have its IANA allocation policies defined, 
   using the proper language from RFC-5226. 

Creativity in specifying an allocation policy is at least strongly 
discouraged and might be disallowed. 

Example edit for Section 12.3: 
   Values 1-16 are defined elsewhere in this document. 
   Values 17-N are to be allocated under the IANA “Specification 
   Required” allocation policy from Section 4.1 of [RFC5226].
   Values N-65534 are reserved for “Private Use” as defined by 
   Section 4.1 of RFC5226.” 

NOTE: I believe that the same kind of edits are needed *throughout* Section 12 “IANA Considerations”. 

2) In Section 8.0, page 20, the existing Table-1 is labelled “The core 
DLEP signals and messages are” but actually contains various values 
that are NOT actually “core DLEP signals and messages”. 

Requested Action: 

Edit this instance of Table 1 to remove the rows corresponding to any 
Type Code value that is NOT considered “core DLEP”. 

3) In Section 9.0, pages 32 & 33, the existing Table-2 is labelled 
“The core DLEP data items are” but the table actually contains various 
values that are NOT actually “core DLEP data items”. 

Requested Action: 

Edit this instance of Table 2 to remove the rows corresponding to any 
Type Code value that is NOT considered “core DLEP”. 

NOTE: I would suggest copying the current Table 2 into Section 12.4 
prior to making the edit here in Section 9. 

4) In Section 9.1, page 35, please copy Table 3 into Section 12.5. 

5) Please add normative citation of [RFC5226] in Section 12 and
   also in the Normative References section.

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Tue, 18 Aug 2015 13:41:20 +0000

Hi Ran,

We are aware that the IANA considerations section needs to be brought 
inline with RFC-5226.  It is our intention to rewrite the section for 
the next draft.

Thanks for the reminder.

Rick

On 17/08/15 21:30, RJ Atkinson wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>