%% You should probably cite rfc7631 instead of this I-D.
@techreport{ietf-manet-tlv-naming-01,
    number =    {draft-ietf-manet-tlv-naming-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/01/},
    author =    {Christopher Dearlove and Thomas H. Clausen},
    title =     {{TLV Naming in the MANET Generalized Packet/Message Format}},
    pagetotal = 16,
    year =      2015,
    month =     feb,
    day =       11,
    abstract =  {TLVs (type-length-value structures) as defined by RFC5444 have both a type (one octet) and a type extension (one octet), together forming a full type (of two octets). RFC5444 sets up IANA registries for TLV types, specifying that an allocation of a TLV type entails creation of an IANA registry for the corresponding type extensions. In some cases, reserving all 256 type extensions for use for a common purpose for a given TLV is meaningful, and thus it makes sense to record a common name for such a TLV type (and all of its type extensions) in the corresponding IANA registries. An example of such is a LINK\_METRIC TLV Type, with its type extensions reserved for use to be indicating the "kind" of metric expressed by the value of the TLV. In some other cases, there may not be 256 full types that share a common purpose and, as such, it is not meaningful to record a common name for all the type extensions for a TLV type in the corresponding IANA registries. Rather, it is appropriate to record an individual name per full type. This document reorganizes the naming of already allocated TLV types and type extensions in those registries to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC5444.},
}