TLS Handshake Message for Supplemental Data
RFC 4680

[Ballot discuss]
The -ume draft is fine.

My discuss on -supp relates to the IANA considerations
that others have raised, but I have a specific worry
that the relatively free allocation policy (Specification
Required) may lead to interoperability problems later.
Since both a supplemental data value and an extensions
data value is required for the correct definition
of a new data item, wouldn't it make sense to keep
the same policy on both supplemental data values and
TLS extensions? RFC 3546bis defines IETF Consensus
for extensions. A small range could be set aside for
private use.

In addition, I have a comment on -supp:
> therefore be defined in each document that defines a supplemetal data
s/supplemetal/supplemental/

IANA Last Call Comments:
Upon approval of this document the IANA will create a new registry for TLS Supplemental Data Formats.  Registration Procedures will be as follows:
range 0-16385 (decimal) are assigned via Standards Action
range 16385-65279 (decimal) are assigned via Specification Required
range 65280-65535 (decimal) are reserved for Private Use

Note: One of the ranges above overlaps and should be fixed. 
Are there any initial assignments in this registry?
Should this new registry be nested at an existing location or should it be a stand-alone registry?

In section 2 there "supplemental_data(TBD), (255)".  Does IANA need to assign this?  If so, from which registry? 
(Thanks to Pasi Eronen for pointing this TBD out)