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

[Kathleen Moriarty <[e-mail]>]

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]> 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 <
> [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
>
>


-- 

Best regards,
Kathleen