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

[Kathleen Moriarty <[e-mail]>]

Thank you, Sabrina.

The radext editors will make the changes, but it is up to the IESG to
approve the document (not the IPFIX experts).

Thanks,
Kathleen

On Mon, Sep 12, 2016 at 2:02 PM, Sabrina Tanamal via RT
<[e-mail]> wrote:
> Dear Authors,
>
> Without approval from the registry experts, we will not be able to complete the registrations completed by this document. Will there be a new version available for review?
>
> Thank you,
>
> Sabrina Tanamal
> IANA Specialist
> ICANN
>
> On Sat Aug 20 00:29:38 2016, amanda.baber wrote:
>> 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
>
>
>



-- 

Best regards,
Kathleen