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

[Dean cheng <[e-mail]>]

Kathleen - thanks for the reminder.

Brain - thanks for the comments, and we've updated
our draft (13.txt) to incorporate your comments see
below.

Cheers,
Dean

From: Kathleen Moriarty [mailto:[e-mail]]
Sent: Tuesday, October 11, 2016 9:35 AM
To: Brian Trammell
Cc: [e-mail]; <[e-mail]>; Jouni Korhonen; Mirja Kuehlewind (IETF); The IESG; [e-mail]; [e-mail]
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS)

Hello Med,

Can you also respond to this message, it contains the details of the IPFIX review.

Thank you,
Kathleen

On Fri, Sep 2, 2016 at 1:07 PM, Brian Trammell <[e-mail]<mailto:[e-mail]>> wrote:
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:

DC>
In the 11.txt, we proposed three new IPFIX IEs and in the 13.txt,
we've removed or updated them as the following:

      11.txt                                 13.txt
      -------------------------------------------------------------------
      transportType                  removed this as an IPFIX IE
      -------------------------------------------------------------------
      natTransportLimit           renamed this IE as " sourceTransportPortsLimit"
                                                  along with revised description.
      -------------------------------------------------------------------
      localID                               removed this as an IPFIX IE

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?

DC>
This IE as proposed in 11.txt has been removed in 13.txt.
We now include "Protocol-Number" defined by IANA,
i.e., the protocol ID, in the Value field of IP-Port-Type TLV.
Protocols that do not use port numbers (such as ICMP)
are not included in this TLV. Please refer to Section 3.2.1 for details.

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".)

DC> No issue here since there is no proposed IE here.

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?)

DC> We changed the name to " sourceTransportPortsLimit"
along with the description. It indicates the limit imposed
to a user on the max source port number, and can be associated
with an IPv4 or IPv6 address. Refer to Section 3.2.2
and 7.1 for details.

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."

DC> We removed this proposed IE in 13.txt. In the Value field
of IP-Port-Local-Id TLV (Section 3.2.11), we now include a "localID"
of "string" as the data type (refer to ietf-radext-datatypes.txt).

Best regards,

Brian Trammell (for the IE-Doctors)


> On 02 Sep 2016, at 18:41, Kathleen Moriarty <[e-mail]<mailto:[e-mail]>> wrote:
>
> On Fri, Sep 2, 2016 at 7:44 AM, Mirja Kuehlewind (IETF)
> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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



--

Best regards,
Kathleen