Subject: [radext] [IANA #922685] expert review for draft-ietf-radext-ip-port-radius-ext (IP Flow Information Export (IPFIX) Entities)

From: "Amanda Baber via RT" <[email-masked]>
Date: Sat, 20 Aug 2016 00:29:38 +0000

Dear Authors,

The experts for the IPFIX IE registry have returned the following review:

In general, the Information Elements in draft-ietf-radext-ip-port-radius-ext are so underspecified as to be unimplementable. They should not be added to the registry in their present form. The authors are advised to read RFC 7013, especially Section 4, which provides useful information on defining Information Elements. Specifically:

The Information Element transportType is underspecified: (a) I presume this is in reference to sourceTransportPort and destinationTransportPort, but the description must say this if it is the case; (b) It's not clear at all from the description in what context this distinction is useful; (c) What's an ICMP identifier?

In addition, the description of transportType appears to create a table which should probably be handled as a subregistry. See See RFC7013 section 4.7. for advice on the creation of tables without subregistries (in short, "don't".)

The Information Element natTransportLimit has an inappropriate name; it does not describe that which it (presumably) is supposed to represent (see RFC 7013 section 4.1). In addition, it is underspecified. It is impossible to implement from the description. Is the field IPv4 specific, or is IPv6 supported as well? (If not, why not?)

The Information Element localID has an inappropriate name; it is far too general (see RFC 7013 section 4.1). It uses an inappropriate abstract data type (addresses should never be represented as UTF-8 strings in IPFIX, see RFC 7013 section 4.2). It is underspecified as well as poorly designed. Without the ability to disambiguate the type of information in the field, this is not a useful Information Element. Without a complete enumeration of possible types (n.b. 'etc.' in the description), it is not a useful Information Element. Its purpose is unclear from its description; further, it appears to violate the following guidance in RFC 7013 section 4: "The Information Element must be unique within the registry, and its description must represent a substantially different meaning from that of any existing Information Element. An existing Information Element that can be reused for a given purpose should be reused."

Best regards,

Amanda Baber
IANA Lead Specialist
ICANN