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

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 11 Oct 2016 12:34:44 -0400

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 <[email-masked]> 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:
>
> 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 <
> [email-masked]> wrote:
> >
> > On Fri, Sep 2, 2016 at 7:44 AM, Mirja Kuehlewind (IETF)
> > <[email-masked]> 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 <
> [email-masked]>:
> >>>
> >>> 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 <
> [email-masked]> 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

---

From: Dean cheng <[email-masked]>
Date: Tue, 11 Oct 2016 19:34:37 +0000

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:[email-masked]]
Sent: Tuesday, October 11, 2016 9:35 AM
To: Brian Trammell
Cc: [email-masked]; <[email-masked]>; Jouni Korhonen; Mirja Kuehlewind (IETF); The IESG; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
hi Kathleen, all,

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,

> On 02 Sep 2016, at 18:41, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
>
> <[email-masked]<mailto:[email-masked]>> wrote:
>> Did finally send someone the review to the right people or should I ping Brian (again)?
>
>>> Am 17.08.2016 um 19:18 schrieb Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>:
>>>
>>> On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen <[email-masked]<mailto:[email-masked]>> 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
>>>>
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/
>>>>>
>>>>> identifiers that may want to be supported in future. Also it is not clear
>>>>> described use cases. Therefore I see two possible ways forward: Either
>>>>> restricted to UDP/TCP and therefore the following sentence in section 2
>>>>> is not correct:
>>>>> 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,

--

Best regards,
Kathleen

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Oct 2016 15:54:41 +0200

Hi Mohamed,

thanks for these changes. Using the IANA protocol number seems to be the 
right thing to do!

One tiny additional question/comment: the term "IP port" or "IP transport 
port" seems a little weird (because ports are in the transport header and not 
in the IP header). Is it important to use this term to indicate that it's IP 
underneath or could you simply speak about "transport ports" instead?

Thanks!
Mirja

On 29.09.2016 08:44, [email-masked] wrote:
> Dear Mirja,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : radext [mailto:[email-masked]] De la part de Mirja
>> Kuehlewind
>> Envoyé : mercredi 17 août 2016 16:04
>> À : The IESG
>> Cc : [email-masked]; MORAND Lionel IMT/OLN;
>> [email-masked]; [email-masked]
>> Objet : [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-port-
>> radius-ext-11: (with DISCUSS)
>>
>> I fully support Alissa's discussion points and have two more to add:
>>
>> identifiers that may want to be supported in future.
>
> [Med] This is a fair comment. FWIW, only TCP/UDP/ICMP are covered initially in the draft because those are currently the only ones supported by widely deployed CGNs.
>
>  Also it is not clear
>> described use cases.
> [Med] Because ports are bound to a transport protocol (e.g., of the port forwarding in Section 4.1.3). In modern NATs, when an (explicit/implicit) mapping is created, a port is reserved only for a given transport protocol not for all transport protocols.
>
>  Therefore I see two possible ways forward: Either
> [Med] The new version of the draft extends the TLV to be applicable to other transport protocols. We are using the IANA protocol numbers (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).
>
>>
> [Med] This is not an issue given that the new version of the draft is not restricted to TCP/UDP.
>

---

From: <[email-masked]>
Date: Wed, 12 Oct 2016 14:15:07 +0000

Hi Mirja, 

Please see inline.

Cheers,
Med

> De : Mirja Kühlewind [mailto:[email-masked]]
> Envoyé : mercredi 12 octobre 2016 15:55
> À : BOUCADAIR Mohamed IMT/OLN; The IESG
> Objet : Re: [radext] Mirja Kühlewind's Discuss on draft-ietf-radext-ip-
> port-radius-ext-11: (with DISCUSS)
> 
> Hi Mohamed,
> 

[Med] Great!

> underneath or could you simply speak about "transport ports" instead?

[Med] We used "IP" on purpose to avoid that the term "port" is misunderstood as referring to a physical port. Using simply "transport port" does not help either to clarify that confusion. This is why we went for explicitly using "IP xxx" to make it clear we are dealing with port numbers that are used by protocols transported over IP.

> > [Med] This is a fair comment. FWIW, only TCP/UDP/ICMP are covered
> initially in the draft because those are currently the only ones supported
> by widely deployed CGNs.
> >
> >  Also it is not clear
> > [Med] Because ports are bound to a transport protocol (e.g., of the port
> forwarding in Section 4.1.3). In modern NATs, when an (explicit/implicit)
> mapping is created, a port is reserved only for a given transport protocol
> not for all transport protocols.
> >
> > [Med] The new version of the draft extends the TLV to be applicable to
> other transport protocols. We are using the IANA protocol numbers
> (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).
> >
> >>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Oct 2016 16:20:49 +0200

I’m okay with that. But why does „transport port“ not clarify this confusion. Or maybe it should be „transport protocol port“ then?

Mirja

> Am 12.10.2016 um 16:15 schrieb [email-masked]:
> 
> Hi Mirja, 
> 
> Please see inline.
> 
> Cheers,
> Med
>

---

From: <[email-masked]>
Date: Wed, 12 Oct 2016 14:24:01 +0000

Re-,

Because "transport port" may be (mis)understood by transmission people as being a transmission port. 

"transport" is one of these overloaded terms. See for example the ongoing efforts about Transport SDN & cie.

Cheers, 
Med

> De : Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Envoyé : mercredi 12 octobre 2016 16:21
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : The IESG; [email-masked]; MORAND
> Lionel IMT/OLN; [email-masked]; [email-masked]
> I’m okay with that. But why does „transport port“ not clarify this
> confusion. Or maybe it should be „transport protocol port“ then?
> 
> Mirja
> 
> 
> >> port" seems a little weird (because ports are in the transport header
> and
> >> not
> >> in the IP header). Is it important to use this term to indicate that
> it's
> >> IP
> > [Med] We used "IP" on purpose to avoid that the term "port" is
> misunderstood as referring to a physical port. Using simply "transport
> port" does not help either to clarify that confusion. This is why we went
> for explicitly using "IP xxx" to make it clear we are dealing with port
> numbers that are used by protocols transported over IP.
> >
> >>
> >> Thanks!
> >> Mirja
> >>
> >>