Re: [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS)

[Brian Trammell <[e-mail]>]

hi Kathleen, all,

Sorry, this fell off my radar, due to the present emergency.

Review text below:

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,

Brian Trammell (for the IE-Doctors)


> On 02 Sep 2016, at 18:41, Kathleen Moriarty <[e-mail]> wrote:
> 
> On Fri, Sep 2, 2016 at 7:44 AM, Mirja Kuehlewind (IETF)
> <[e-mail]> wrote:
>> Did finally send someone the review to the right people or should I ping Brian (again)?
> 
> That would be helpful, I believe we are still waiting for the review.
> 
> Thanks,
> Kathleen
> 
>> 
>> Mirja
>> 
>> 
>>> Am 17.08.2016 um 19:18 schrieb Kathleen Moriarty <[e-mail]>:
>>> 
>>> Apparently, Brian did the review.  I'm adding him to this thread so he
>>> can send the review to the draft distribution list.
>>> 
>>> Thank you,
>>> Kathleen
>>> 
>>> On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen <[e-mail]> wrote:
>>>> Hi,
>>>> 
>>>> Would it be possible to see the IE doctor's feedback? The authors might find
>>>> it useful as well. If it has been distributed already, my apologies if I
>>>> missed it.
>>>> 
>>>> regards,
>>>>       Jouni
>>>> 
>>>> 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti:
>>>>> 
>>>>> Mirja Kühlewind has entered the following ballot position for
>>>>> draft-ietf-radext-ip-port-radius-ext-11: Discuss
>>>>> 
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)
>>>>> 
>>>>> 
>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>> 
>>>>> 
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/
>>>>> 
>>>>> 
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> I fully support Alissa's discussion points and have two more to
>>>>> add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/
>>>>> 
>>>>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very
>>>>> future-proof: there are other transport protocols that have ports or
>>>>> identifiers that may want to be supported in future. Also it is not clear
>>>>> to me from the document why this information is needed at all in the
>>>>> described use cases. Therefore I see two possible ways forward: Either
>>>>> remove the IP-Port-Type TLV or extend it to also cover other cases.
>>>>> 
>>>>> Related to this point I would like to mention that RFC6887 is not
>>>>> restricted to UDP/TCP and therefore the following sentence in section 2
>>>>> is not correct:
>>>>> "Note that the definitions of [...] "internal port", [...] "external
>>>>> port" [...] are the same as defined in Port Control Protocol (PCP)
>>>>> [RFC6887]"
>>>>> 
>>>>> 2) The IE doctors have provide feedback to IANA that the Information
>>>>> Elements in this doc are underspecified (not confirm with rules in RFC
>>>>> 7013) and should therefore be not registered.  Addressing this feedback
>>>>> could lead to a mayor rewrite of this doc, especially in the relation to
>>>>> the use and definition of transportType and receptively IP-Port-Type TLV,
>>>>> and should therefore be done before a final IESG decision.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Best regards,
>>> Kathleen
>>> 
>> 
> 
> 
> 
> --
> 
> Best regards,
> Kathleen