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

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 12:25:12 -0500

RFC 5246 (http://www.ietf.org/rfc/rfc5246.txt) has some
"IANA Considerations” text that might be helpful as an
example to the authors in trying to write clearer text 
for DLEP’s IANA Considerations.

The text for “TLS SignatureAlgorithm Registry” is useful
as an example of what text generally looks like for a
newly defined IANA registry.

For each new IANA Registry, one ought to define, and the 
RFC-5246 text on page 66 generally does define:
  - NAME of the registry (e.g. TLS SignatureAlgorithm Registry)
  - INITIAL VALUES of the registry (e.g. reference to Table N)
  - ASSIGNMENT POLICIES for future values of the registry,
    including explicit reservation of “Private Use” values.
  - RFC REFERENCE (This should be a reference to the DLEP RFC
    for the case of DLEP registries created by the DLEP draft.)

If the DLEP-17 text for “IANA Considerations” were much more 
consistent with the IANA Considerations text from RFC-5246,
that would be very helpful, and likely would get that section
to where it really ought to be.

The WG also might want to consider having multiple sections of 
reserved numbers, each with its own allocation policy, as TLS does.
For example, for a given registry, some (lower) numbers might be 
allocated only by “Standards Action”, while other (middle) numbers 
might be allocated only by “Specification Required” or “Expert Review”, 
all while retaining a “Private Use” block in the (upper) numbers.

Yours,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Nov 2015 17:36:48 +0000

> all while retaining a “Private Use” block in the (upper) numbers.

My gut feeling is that Messages should require Standards Action as they 
alter the protocol, where-as new metrics might only need Specification 
Required.

We will certainly give it some thought.

Cheers,

Rick

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 15:26:35 -0500

> On 24  Nov 2015, at 12:36 , Rick Taylor <[email-masked]> wrote:
> 

At least at first glance, that seems plausible to me.  

I don’t immediately see as many situations where a new Signal/
Message Type really is needed, given the set that exist now.

By contrast, I can see lots of situations where use of some 
new radio might be optimized by specifying some additional 
Data Types.

I need to give Status Codes more thought.

> We will certainly give it some thought.

Thanks,

Ran