[Dime] Adding a new derived type

[Tom Taylor <[e-mail]>]

I have wondered from time to time why the derived AVP data formats in 
RFC 6733 Section 4.3 were not a little more general. In particular, it 
would be nice to have an address-or-prefix type rather than just an 
address, and an FQDN broken out from DiameterIdentity.

This is to lead in to our latest revision of 
draft-zhou-dime-4over6-provisioning, which, alas, I forgot to submit 
before the deadline. Within the updated document, several attributes are 
either addresses or prefixes. Reading the introduction to Section 4.3, I 
gathered that defining a new derived AVP data format is permissible, 
although none has been registered with IANA as they are supposed to be. 
I present below the current text of the unsubmitted 
draft-zhou-dime-4over6-provisioning-03 that defines a new derived AVP 
data format, AddressOrPrefix.

Comments?

Tom Taylor

3.  Derived AVP Data Formats: AddressOrPrefix

    The above requirements involve IP addresses and prefixes in a number
    of contexts.  To simplify specification of these attributes, this
    section defines a new derived AVP data format, AddressOrPrefix,
    according to the rules given in Section 4.3 of [RFC6733].

    AddressOrPrefix

       The AddressOrPrefix data format is an extension of the Address
       data format defined in Section 4.3.1 of [RFC6733].  Like the
       Address data format, it is derived from the OctetString basic AVP
       format.  As well as an AddressType, it contains a PrefixLength
       field.  The detailed specification is as follows:

       *  As with the Address AVP, the first two octets represent the
          AddressType, which contains an Address Family, defined in
          [IANAADFAM].

       *  The next two octets are interpreted as a 16-bit unsigned
          integer representing the PrefixLength.  Valid values of
          PrefixLength are from 0 to 32 for IPv4 and from 0 to 128 for
          IPv6.  The value 0 is included in each range to allow for
          presentation of a "null prefix", the meaning of which must be
          defined by applications that use AVPs based on the
          AddressOrPrefix data format.

       *  The remaining octets present the prefix or address, most
          significant octet first.  If the prefix does not extend to an
          octet boundary, the low-order bits of the final octet are
          padded with zeroes.