Subject: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06

From: <[email-masked]>
Date: Tue, 1 Mar 2016 17:23:27 +0000

Hi,

Acting as Shepherd of the document draft-ietf-radext-ip-port-radius-ext-06, I have the following comments on the draft.
Most of the comments can be simply addressed with a new version of the draft before IESG submission.

The main comments to take into consideration are the following:
- Attributes can be pre-allocate as Extended-Type-1  attributes
- Sub-attribute type must be defined by encapsulating attributes. There is therefore no unique type. See comment on IANA section.

Please see hereafter further details on the changes .

Regards,

Lionel

***************

Abstract

   This document defines three new RADIUS attributes.  For devices that
   implementing IP port ranges, these attributes are used to communicate
   with a RADIUS server in order to configure and report TCP/UDP ports
   and ICMP identifiers, as well as mapping behavior for specific hosts.
   This mechanism can be used in various deployment scenarios such as
   CGN (Carrier Grade NAT), NAT64, Provider WLAN Gateway, etc.

Usually, we need to limit the use of acronym in the abstract when not required.
A proposal would be:

s/CGN (Carrier Grade NAT)/Carrier-Grade NAT
s/NAT64/IPv6/IPv4 gateway

******

1.  Introduction

   "In a broadband network, customer information is usually stored on a
   RADIUS server [RFC2865] and at the time when a user initiates an IP
   connection request, the RADIUS server will populate the user's
   configuration information to the Network Access Server (NAS), which
   is usually co-located with the Border Network Gateway (BNG), after
   the connection request is granted." 

In a broadband network --> In broadband access network
Border Network Gateway (BNG) --> Broadband Network Gateway (BNG)

comment: In Broadband access network, the BNG acts as a NAS ( not collocated with)

Porposed modificiation:

   In a broadband network, customer information is usually stored on a
   RADIUS server [RFC2865] and at the time when a user initiates an IP
   connection request and this request is authorized, the RADIUS server 
   will populate the user's configuration information to the Network 
   Access Server (NAS), which is often referred to as a Broadband 
   Network Gateway (BNG) in broadband access networks. 

Comment: check the consistency all acrossthe document regarding NAS/BNG

*******

   "The Carrier Grade NAT (CGN)
   function may also be implemented on the BNG, and therefore the CGN
   TCP/UDP port (or ICMP identifier) mapping(s) behavior(s) can be
   configured on the RADIUS server as part of the user profile, and
   populated to the NAS in the same manner."

Proposed modification:

   The Carrier-Grade NAT (CGN)
   function may also be implemented on the BNG. In such a case, the CGN
   TCP/UDP port (or ICMP identifier) mapping(s) behavior(s) can be
   part of the configuration information sent from the RADIUS server to the
   NAS/BNG.

*******

   "In addition, during the
   operation, the CGN can also convey port/identifier mapping behavior
   specific to a user to the RADIUS server, as part of the normal RADIUS
   accounting process."

Comment: the NAS/BNG is ont that exhanges withthe server, not the CGN.

Proposed modification:

   "The NAS/BNG may also report to the RADIUS Server the port/identifier mapping 
   behavior applied by the CGN to a user session to the RADIUS server, as part of the 
   accounting information sent from the NAS/BNG to a RADIUS server."

*******

   "The CGN device that communicates with a RADIUS server using RADIUS
   extensions defined in this document may perform NAT44 [RFC3022],
   NAT64 [RFC6146], or Dual-Stack Lite AFTR [RFC6333] function."

Comment: the CGN does not communicate with the RADIUS server. And not sure that it is needed to speak about that here.

proposed modification:

    The CGN may perform NAT44 [RFC3022], NAT64 [RFC6146], or Dual-Stack 
    Lite AFTR [RFC6333] function.

comment: difficult to see the link between this text and what is before and after. Is it required here?

*******

   "For the CGN case, when IP packets traverse a CGN device, it would
   perform TCP/UDP source port mapping or ICMP identifier mapping as
   required."

Proposed simplification:

   When IP packets traverse the CGN, it performs TCP/UDP source port 
   mapping or ICMP identifier mapping as required.
 
********

   "This is required for identification purposes (see TR-146 [TR-146] for
   example)."

"for more details" would be more appropriate.

********

   "1.  IP-Port-Limit: This attribute may be carried in RADIUS Acces-
       Accept, Access-Request, Accounting-Request or CoA-Request packet.
       The purpose of this attribute is to limit the total number of
       TCP/UDP ports and/or ICMP identifiers that an IP subscriber can
       use, associated with one or more IPv4 addresses."

s/RADIUS Acces-Accept/RADIUS Access-Accept

s/IP subscriber/user ???

********

   "2.  IP-Port-Range: This attribute may be carried in RADIUS
       Accounting-Request packet.  The purpose of this attribute is to
       report by an address sharing device (e.g., a CGN) to the RADIUS
       server the range of TCP/UDP ports and/or ICMP identifiers that
       have been allocated or deallocated associated with a given IPv4
       address for a subscriber."

s/subscriber/user ???

*******

   "3.  IP-Port-Forwarding-Map: This attribute may be carried in RADIUS
       Access-Accept, Access-Request, Accounting-Request or CoA-Request
       packet.  The purpose of this attribute is to specify how a TCP/
       UDP port (or an ICMP identifier) mapping to another TCP/UDP port
       (or an ICMP identifier), and each is associated with its
       respective IPv4 address."

the last sentence is not clear.

Proposed change (to check/clarify):

       The purpose of this attribute is to specify how a TCP/
       UDP port (or an ICMP identifier) is mapped to another TCP/UDP port
       (or an ICMP identifier), and how each mapping is associated with its
       respective IPv4 address.

********

   "This document leverages the protocol defined in [RFC7012] by
   proposing a mapping between type field of RADIUS TLV and Element ID
   of IPFIX.  It also proposes a few new IPFIX Elements as required by
   this document (see Section 3)."

The protocol is defined in RFC7011. The RFC7012 defines the information model.
What does "leverage" mean here?
And you should explain why the link between RADIUS and IPFIX is required.

Here is a proposal:

   IPFIX Elements [RFC7011] can be used for IP flow identification and 
   representation over RADIUS. This document provides a mapping between
   RADIUS TLV and IPFIX ElementIDs. As a consequence, new IPFIX Elements
   are defined by this document (see Section 3).

*******

   "This document was constructed using the [RFC2629]."
can be removed.

******

2.  Terminology

   This document makes use if the following terms:

s/makes use if/makes use of

******

   o  IP Port Range: specifies a set of contiguous IP ports, indicated
      by the smallest numerical number and the largest numerical number,
      inclusively.

s/smallest/lowest
s/largest/highest

******

   o  Internal IP Address: refers to the IP address that is used as a
      source IP address in an outbound IP packet sent towards a device
      supporting port ranges in the internal realm.  In the IPv4 case,
      it is typically a private address [RFC1918].

When defining "Internal IP Address", is the last sentence really required?
Otherwise, you would have to describe the otehr possible cases, that it is not needed at this stage.

******

   o  External IP Address: refers to the IP address that is used as a
      source IP address in an outbound IP packet after traversing a
      device supporting port ranges in the external realm.  In the IPv4
      case, it is typically a global routable IP address.

same comment

******

   o  External realm: refers to the networking segment where IPv4 public
      addresses are used in respective of the device supporting port
      ranges.

s/where IPv4 public addresses/where external IP addresses

   o  Internal realm: refers to the networking segment that is behind a
      device supporting port ranges and where IPv4 private addresses are
      used.

S/where IPv4 private addresses/where internal IP addresses

*******

   Note the terms "internal IP address", "internal port", "internal
   realm", "external IP address", "external port", "external realm", and
   "mapping" and their semantics are the same as in [RFC6887], and
   [RFC6888].

proposed change (for clarity):

   Note the definitions of "internal IP address", "internal port", "internal
   realm", "external IP address", "external port", "external realm", and
   "mapping" are the same as defined in Port Control Protocol (PCP) [RFC6887], and
   the Common Requirements for Carrier-Grade NATs (CGNs)[RFC6888].

*****

3.  Extensions of RADIUS Attributes and TLVs

 [...]

I propose to add here the following text.

   In all the figures describing the RADIUS attribute and TLV formats in the 
   following sections, the fields are transmitted from left to right.

With this text in the introduciton, no need to repeat it in all the other sections.
And it was actually missing in some of them.

*****

3.1.1.  IP-Port-Limit Attribute

   This attribute is RADIUS Extended-Type, and contains a set of
   embedded TLVs defined in Section 3.2.1 (IP-Port-Type TLV),
   Section 3.2.2 (IP-Port-Limit TLV), and Section 3.2.3 (IP-Port-Ext-
   IPv4-Addr TLV).

proposed change:

   This attribute is of type "TLV" as defined in the 
   RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attributes:
   - an IP-Port-Type TLV (see section 3.2.1), 
   - an IP-Port-Limit TLV (see Section 3.2.2),
   - an optional IP-Port-Ext-IPv4-Addr TLV (see section 3.2.3).

*****

   Note that when IP-Port-Ext-IPv4-Addr TLV is not included as part of
   the IP-Port-Limit Attribute, the port limit is applied to all the
   IPv4 addresses managed by the port device, e.g., a CGN or NAT64
   device.

s/the port limit is applied to/the port limit applies to

*****

   The IP-Port-Limit Attribute MAY appear in an Access-Accept packet.
   It MAY also appear in an Access-Request packet as a hint by the
   device supporting port ranges, which is co-allocated with the NAS, to
   the RADIUS server as a preference, although the server is not
   required to honor such a hint.

Proposed change:

   It MAY also appear in an Access-Request packet as a preferred maximum 
   number of IP ports indicated by the device supporting port ranges 
   co-allocated with the NAS e.g. a CGN or NAT64. However, the RADIUS 
   server is not required to honor such a preference.

*****

   The IP-Port-Limit Attribute MUST NOT appear in any other RADIUS
   packets.

s/any other RADIUS packets/any other RADIUS packet

*******

   Type:

      TBA1.

proposed change:

   Type:

      241 (To be confirmed by IANA).

*******

   IP-Port-Limit attribute is associated with the following identifier:
   Type(TBA1).Extended-Type(TBA2).[IP-Port-Limit TLV (TBA6),IP-Port-Type
   TLV(TBA5), {IP-Port-Ext-IPv4-Addr TLV(TBA7)}].

What is defined is a new type space. therefore the text should be only:

  IP-Port-Limit attribute is associated with the following identifier:
  241.TBA2.

******

3.1.2.  IP-Port-Range Attribute

   This attribute is RADIUS Extended-Type, and contains a set of
   embedded TLVs defined in Section 3.2.1 (IP-Port-Type TLV), Section
   3.2.9 (IP-Port-Range-Start TLV), Section 3.2.10 (IP-Port-Range-End
   TLV), Section 3.2.8 (IP-Port-Alloc TLV), Section 3.2.3 (IP-Port-Ext-
   IPv4-Addr TLV), and Section 3.2.11 (IP-Port-Local-Id TLV).

Proposed change:

   This attribute is of type "TLV" as defined in the 
   RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attributes:
   - an IP-Port-Type TLV (see section 3.2.1),
   - an IP-Port-Range-Start TLV (see section 3.2.9),
   - an IP-Port-Range-End TLV (see section 3.2.10),
   - an IP-Port-Alloc TLV (see section 3.2.8),
   - an optional IP-Port-Ext-IPv4-Addr TLV (see section 3.2.3),
   - an optonal IP-Port-Local-Id TLV (see section 3.2.11).

******

   This attribute contains a range of contiguous IP ports of a specific
   port type and associated with an IPv4 address that are either
   allocated or deallocated by a device for a given subscriber, and the
   information is intended to send to RADIUS server.

s/is intended to send/is intended to be sent

*******

   The IP-Port-Range Attribute MUST NOT appear in any other RADIUS
   packets.

s/any other RADIUS packets/any other RADIUS packet

*******

   Type:

      TBA1.

Proposed change:

   Type:

      241 (To be confirmed by IANA).

*******

   The IP-Port-Range attribute is associated with the following
   identifier: Type(TBA1).Extended-Type(TBA3).[IP-Port-Alloc TLV
   (TBA12), IP-Port-Type TLV(TBA5), {IP-Port-Range-Start TLV(TBA13), IP-
   Port-Range-End TLV(TBA14)}, {IP-Port-Ext-IPv4-Addr TLV (TBA7)}, {IP-
   Port-Local-Id TLV (TBA15)}].

same comment as baove regarding type space:

   The IP-Port-Range attribute is associated with the following
   identifier: 241.TBA3.

******

3.1.3.  IP-Port-Forwarding-Map Attribute

   This attribute is RADIUS Extended-Type, and contains a set of
   embedded TLVs defined in Section 3.2.1(IP-Port-Type TLV), Section
   3.2.6(IP-Port-Int-Port TLV), Section 3.2.7(IP-Port-Ext-Port TLV),
   Section 3.2.4(IP-Port-Int-IPv4-Addr TLV) or Section 3.2.5(IP-Port-
   Int-IPv6-Addr TLV), Section 3.2.11(IP-Port-Local-Id TLV) and
   Section 3.2.3 (IP-Port-Ext-IP-Addr TLV).

"IP-Port-Ext-IP-Addr TLV" should be "IP-Port-Ext-IPv4-Addr TLV" if I'm correct

Proposed change:

   This attribute is of type "TLV" as defined in the 
   RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attributes:
   - an IP-Port-Type TLV (see section 3.2.1),
   - an IP-Port-Int-Port TLV (see section 3.2.6),
   - an IP-Port-Ext-Port TLV (see section 3.2.7),
   - either an IP-Port-Int-IPv4-Addr TLV (see section 3.2.4) or an 
     IP-Port-Local-Id TLV (see section 3.2.11), 
   - either an IP-Port-Int-IPv6-Addr TLV (see section 3.2.5) or an 
     an IP-Port-Local-Id TLV (see section 3.2.11),
   - an IP-Port-Ext-IPv4-Addr TLV (see section 3.2.3).

*******

   The attribute MUST NOT appear in any other RADIUS packet.

s/The attribute MUST NOT/The IP-Port-Forwarding-Map Attribute

*******

   Type:

      TBA1.

Proposed change:

   Type:

      241 (To be confirmed by IANA).

********

   The IP-Port-Forwarding-Map attribute is associated with the following
   identifier: Type(TBA1).Extended-Type(TBA4).  [IP-Port-Int-Port
   TLV(TBA10), IP-Port-Ext-Port TLV(TBA11), IP-Port-Type TLV(TBA5), {IP-
   Port-Int-IPv4-Addr TLV(TBA8) | IP-Port-Int-IPv6-Addr TLV(TBA9)}, {IP-
   Port-Ext-IPv4-Addr TLV(TBA7)}].

same comment as baove regarding type space:

   The IP-Port-Forwarding-Map attribute is associated with the following
   identifier: 241.TBA4.

*******

3.2.1.  IP-Port-Type TLV

   This TLV (Figure 4) uses the format defined in [RFC6929].  Its Type
   field contains a value that uniquely refers to IPFIX Element
   transportType (TBAx1), and its Value field contains IPFIX Element
   transportType, which indicates the type of IP transport type as
   follows:

s/Its Type field/Its "Type" field
s/its Value field/its "Value" field
s/refers to IPFIX Element transportType (TBAx1)/refers to IPFIX Information Element "transportType" (TBAx1)
s/contains IPFIX Element transportType/contains the values defined for the IPFIX Information Element "transportType"

comment: the same applies for the TLV defined in this document. (section 3.2.1 to 3.2.11) 

s/indicates the type of IP transport type/indicates the type of IP transport

******

Just before figure 4, Add:

   IP-Port-Type TLV is included as part of the IP-Port-
   Limit Attribute (refer to Section 3.1.1), IP-Port-Range Attribute
   (refer to Section 3.1.2), and IP-Port-Forwarding-Map Attribute (refer
   to Section 3.1.3).

******
   Type:

      TBA5:This uniquely refers to IPFIX Element ID TBA0.

proposed change:

   Type:

      The value depends on the encapsulating attribute (see IANA section). This Must uniquely refer to IPFIX ElementID TBA0.

comment: same comment for all the TLV

******

   transportType:

      Integer.  This field contains the data (unsigned8) of
      transportType (TBX1) defined in IPFIX, right justified, and the
      unused bits in this field must be set to zero.

must be --> MUST be ?

*****

3.2.2.  IP-Port-Limit TLV

   This TLV (Figure 5) uses the format defined in [RFC6929].  Its Type
   field contains a value that uniquely refers to IPFIX Element
   natTransportLimit (TBAx2), and its Value field contains IPFIX Element
   natTransportLimit, which indicates the maximum number of ports of a
   specified IP-Port-Type and associated with a given IPv4 address
   assigned to a subscriber.

Should the last sentence be reversed?

"...which indicates the maximum number of ports for a given IPv4 address assigned
to a subscriber for a specified IP-Port-Type."

******

Just before figure 5, Add:

   IP-Port-Limit TLV is included as part of the IP-Port-
   Limit Attribute (refer to Section 3.1.1).

******

   natTransportLimit:

      Integer.  This field contains the data (unsigned16) of
      natTransportLimit (TBX2) defined in IPFIX, right justified, and
      the unused bits in this field must be set to zero.

must be --> MUST be?

*****

3.2.3.  IP-Port-Ext-IPv4-Addr TLV

   [...]

   IP-Port-Ext-IPv4-Addr TLV can be included as part of the IP-Port-
   Limit Attribute (refer to Section 3.1.1), IP-Port-Range Attribute
   (refer to Section 3.1.2), and IP-Port-Forwarding-Map Attribute (refer
   to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

3.2.4.  IP-Port-Int-IPv4-Addr TLV

   [...]

   IP-Port-Int-IPv4-Addr TLV can be included as part of the IP-Port-
   Forwarding-Map Attribute (refer to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

3.2.5.  IP-Port-Int-IPv6-Addr TLV

   [...].

   IP-Port-Int-IPv6-Addr TLV can be included as part of the IP-Port-
   Forwarding-Map Attribute (refer to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

3.2.11.  IP-Port-Local-Id TLV

   [...]

   IP-Port-Local-Id TLV can be included as part of the IP-Port-Range
   Attribute (refer to Section 3.1.2) and IP-Port-Forwarding-Map
   Attribute (refer to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

4.1.  Managing CGN Port Behavior using RADIUS

   In a broadband network, customer information is usually stored on a
   RADIUS server, and the BNG hosts the NAS. 

s/BNG hosts the NAS/BNG acts as a NAS

*****

   A CGN function in a broadband network would most likely reside on a
   BNG.  

s/likely reside/likely collocated

*****

4.1.1.  Configure IP Port Limit for a User

   In the face of IPv4 address shortage, there are currently proposals
   to multiplex multiple subscribers' connections over a smaller number
   of shared IPv4 addresses, such as Carrier Grade NAT [RFC6888], Dual-
   Stack Lite [RFC6333], NAT64 [RFC6146], etc.  As a result, a single
   IPv4 public address may be shared by hundreds or even thousands of
   subscribers.  As indicated in [RFC6269], it is therefore necessary to
   impose limits on the total number of ports available to an individual
   subscriber to ensure that the shared resource, i.e., the IPv4 address
   remains available in some capacity to all the subscribers using it,
   and port limiting is also documented in [RFC6888] as a requirement.

s/resource, i.e., the IPv4 address/resource, i.e., the IPv4 address,

s/using it, and port limiting is also documented in [RFC6888] as a requirement/
using it. The support of IP port limit is also documented in [RFC6888] as a requirement for CGN.

*****

   The per-subscriber based IP port limit is configured on a RADIUS
   server, along with other user information such as credentials.  The
   value of these IP port limit is based on service agreement and its
   specification is out of the scope of this document.

s/The value of these IP port limit/he value of this IP port limit

*****

   When a subscriber signs in to the Internet service successfully, the
   IP port limit for the subscriber is passed to the BNG based NAS,
   where CGN also locates, using a new RADIUS attribute called IP-Port-
   Limit (defined in Section 3.1.1), along with other configuration
   parameters.

proposed change:

   When a subscriber signs in to the Internet service successfully, the
   IP port limit for the subscriber is passed by the RADIUS server to the BNG,
   acting as a NAS and collocated with the CGN, using a new RADIUS attribute 
   called IP-Port-Limit (defined in Section 3.1.1), along with other configuration
   parameters.

******

Figure 17/18/19: use NAT44 or only NAT in the fugures for consistency

*****

5.  Table of Attributes

   This document proposes three new RADIUS attributes and their formats
   are as follows:

   o  IP-Port-Limit: TBA1.TBA2.[TBA6, TBA5, {TBA7}]

   o  IP-Port-Range: TBA1.TBA3.[TBA12, TBA5, {TBA13, TBA14}, {TBA7},
      {TBA15}].

   o  IP-Port-Forwarding-Map: TBA1.TBA4.[TBA10, TBA11, TBA5, {TBA8 |
      TBA9}, {TBA7}]

proposed change(see IANA section):

5.  Table of Attributes

   This document proposes three new RADIUS attributes and their formats
   are as follows:

   o  IP-Port-Limit: 241.TBA2

   o  IP-Port-Range: 241.TBA3

   o  IP-Port-Forwarding-Map: 241.TBA4

Note to IANA: it is assumed that Extended-Type-1 "241" will be used for theses attributes

********

6.  Security Considerations

   This document does not introduce any security issue than what has
   been identified in [RFC2865].

proposed change:

   This document does not introduce any security issue other than the 
   ones already identified in RADIUS [RFC2865].

*******

7.1.  IANA Considerations on New IPFIX Elements

s/IPFIX Elements/IPFIX Information Elements

********

   The following are code point assignments for new IPFIX Elements as
   requested by this document:

s/for new IPFIX Elements/for new IPFIX Information Elements

****

   o  transportType (refer to Section 3.2.1): The identifier of this
      IPFIX Element is TBAx1.  The data type of this IPFIX Element is
      unsigned8, and the Element's value indicates TCP/UDP ports and
      ICMP Identifiers (1), TCP/UDP ports (2), TCP ports (3), UDP ports
      (4) or ICMP identifiers (5).

s/this IPFIX Element/this IPFIX Information Element 

*****

   o  natTransportLimit (refer to Section 3.2.2): The identifier of this
      IPFIX Element is TBAx2.  The data type of this IPFIX Element is
      unsigned16, and the Element's value is the max number of IP
      transport ports to be assigned to an end user associated with one
      or more IPv4 addresses.

s/this IPFIX Element/this IPFIX Information Element 

*****

   o  localID (refer to Section 3.2.11): The identifier of this IPFIX
      Element is TBAx3.  The data type of this IPFIX Element is string,
      and the Element's value is an IPv4 or IPv6 address, a MAC address,
      a VLAN ID, etc.

s/this IPFIX Element/this IPFIX Information Element 

******

Proposed change for IANA (see below for nested TLVs):

7.2.  IANA Considerations on New RADIUS Attributes

   The authors request that Attribute Types and Attribute Values defined
   in this document be registered by the Internet Assigned Numbers
   Authority (IANA) from the RADIUS namespaces as described in the "IANA
   Considerations" section of [RFC3575], in accordance with BCP 26
   [RFC5226].  For RADIUS packets, attributes and registries created by
   this document IANA is requested to place them at
   http://www.iana.org/assignments/radius-types.

   In particular, this document defines three new RADIUS attributes,
   entitled "IP-Port-Limit" (see Section 3.1.1), "IP-Port-Range" 
   (see Section 3.1.2) and "IP-Port-Forwarding-Map" (see Section 3.1.3),
   with assigned values of 241.TBD2, 241.TBD3 and 241.TBD4 from the 
   Short Extended Space of [RFC6929]:

   Type       Name                   Meaning
   ----       ----                   -------
   241.TBD2   IP-Port-Limit          see Section 3.1.1
   241.TBD3   IP-Port-Range          see Section 3.1.2
   241.TBD4   IP-Port-Forwarding-Map see Section 3.1.3

******

Comment: The TLVs are defined within a given extended-Type attribute space.

proposed modification:

7.3.  IANA Considerations on New RADIUS Nested Attributes

   This specification requests allocation of the following TLVs
   within the attribute IP-Port-Limit 241.TBD2:

   Type            Name                  Meaning
   ----            ----                  -------
   241.TBD2.1      IP-Port-Type          see Section 3.2.1
   241.TBD2.2      IP-Port-Limit         see Section 3.2.2
   241.TBD2.2      IP-Port-Ext-IPv4-Addr see Section 3.2.3

   This specification requests allocation of the following TLVs
   within the attribute IP-Port-Range 241.TBD3:

   Type            Name                  Meaning
   ----            ----                  -------
   241.TBD3.1      IP-Port-Type          see Section 3.2.1
   241.TBD3.2      IP-Port-Ext-IPv4-Addr see Section 3.2.3
   241.TBD3.3      IP-Port-Alloc         see Section 3.2.8
   241.TBD3.4	   IP-Port-Range-Start   see Section 3.2.9
   241.TBD3.5      IP-Port-Range-End     see Section 3.2.10

   This specification requests allocation of the following TLVs
   within the attribute IP-Port-Forwarding-Map 241.TBD4:

   Type            Name                  Meaning
   ----            ----                  -------
   241.TBD4.1      IP-Port-Type          see Section 3.2.1
   241.TBD4.2      IP-Port-Ext-IPv4-Addr see Section 3.2.3
   241.TBD4.3      IP-Port-Int-IPv4-Addr see Section 3.2.4
   241.TBD4.4      IP-Port-Int-IPv6-Addr see Section 3.2.5
   241.TBD4.5      IP-Port-Int-Port      see Section 3.2.6
   241.TBD4.6      IP-Port-Ext-Port      see Section 3.2.7
   241.TBD4.7      IP-Port-Local-Id      see Section 3.2.11

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Dean cheng <[email-masked]>
Date: Thu, 10 Mar 2016 01:09:22 +0000

Hi Lionel, 

Thank you very much for your careful review and
suggestions along with proposed text. We have
incorporated all of your comments and posted
the 07 text.

Please review and let us know if there is any
other comments, and we look forward to your
submission to IESG.

Regards
Draft authors

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 01, 2016 9:23 AM
> To: [email-masked]
> Cc: Alan DeKok; Stefan Winter; draft-ietf-radext-ip-port-radius-
> [email-masked]
> Subject: Shepherd review of draft-ietf-radext-ip-port-radius-06
> 
> Hi,
> 
> Acting as Shepherd of the document draft-ietf-radext-ip-port-radius-ext-06,
> I have the following comments on the draft.
> - Sub-attribute type must be defined by encapsulating attributes. There is
> therefore no unique type. See comment on IANA section.
> 
> In a broadband network --> In broadband access network Border Network
> Gateway (BNG) --> Broadband Network Gateway (BNG)
> 
> Comment: the CGN does not communicate with the RADIUS server. And not sure
> that it is needed to speak about that here.
> 
> proposed modification:
> 
> s/refers to IPFIX Element transportType (TBAx1)/refers to IPFIX Information
> Element "transportType" (TBAx1) s/contains IPFIX Element
> transportType/contains the values defined for the IPFIX Information Element
> "transportType"
> 
>       The value depends on the encapsulating attribute (see IANA section).
> This Must uniquely refer to IPFIX ElementID TBA0.
> 
> "...which indicates the maximum number of ports for a given IPv4 address
> assigned to a subscriber for a specified IP-Port-Type."
> 
> 
> ******
> 
> s/using it, and port limiting is also documented in [RFC6888] as a
> requirement/ using it. The support of IP port limit is also documented in
> [RFC6888] as a requirement for CGN.
> 
> *****
> 
> ___________________________________________________________________________
> ______________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

Subject: I-D Action: draft-ietf-radext-ip-port-radius-ext-07.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 10 Mar 2016 00:57:06 +0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions of the IETF.

        Title           : RADIUS Extensions for IP Port Configuration and Reporting
        Authors         : Dean Cheng
                          Jouni Korhonen
                          Mohamed Boucadair
                          Senthil Sivakumar
	Filename        : draft-ietf-radext-ip-port-radius-ext-07.txt
	Pages           : 37
	Date            : 2016-03-09

Abstract:
   Carrier Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: <[email-masked]>
Date: Thu, 10 Mar 2016 15:22:44 +0000

Hi Authors,

thank you for your prompt feedback and the update.

Here are some additional (small) corrections and two comments:

- Overall comment: For sake of clarity, even if there is no impact on the protocol, it could be better to avoid to use the same name "IP-Port-Limit" for the attribute and the sub-attribute.
What about "IP-Port-Limit-Info" (or something else) for the attribute name? 

- Comment: the TDB values start with TBD2 (as TBD1 was replaced by 241). You can keep the numbering as it is but don't forget this point when IANA will handle the document and will wondering where the TBD1 is hidden :)

Corrections:

- abstract:

s/Carrier Grade NAT/Carrier-Grade NAT

- Section 3.2.2

Type:

      TBD2.2.  It MUST uniquely refer to the IPFIX Information Element
      identifier TBAx2.

TB2.2. --> 241.TB2.2

- Section 3.2.4

   Type:

      TBD4.3.  It MUST uniquely refer to the IPFIX Information Element
      identifier 8.

TBD4.3.  --> 241.TBD4.3

- Section 3.2.5

  Type:

      TBD4.4.  It MUST uniquely refer to the IPFIX Information Element
      identifier 27.

TBD4.4.  --> 241.TBD4.4

- Section 3.2.6

  Type:

      TBD4.5.  It MUST uniquely refer to the IPFIX Information Element
      identifier 7.

TBD4.5.  --> 241.TBD4.5

- Section 3.2.7

  Type:

      TBD4.6.  It MUST uniquely refer to the IPFIX Information Element
      identifier 227 .

TBD4.6.  --> 241.TBD4.6

- Section 3.2.8

  Type:

      TBD3.3.  It MUST uniquely refer to the IPFIX Information Element
      identifier 230 .

TBD3.3.  --> 241.TBD3.3

- Section 3.2.9

   Type:

      TBD3.4.  It MUST uniquely refer to the IPFIX Information Element
      identifier 361.

TBD3.4.  --> 241.TBD3.4

- Section 3.2.10

   Type:

      TBD3.5.  It MUST uniquely refer to the IPFIX Information Element
      identifier 362.

TBD3.5.  --> 241.TBD3.5

Regards,

Lionel

> -----Message d'origine-----
> De : Dean cheng [mailto:[email-masked]]
> Envoyé : jeudi 10 mars 2016 02:09
> À : MORAND Lionel IMT/OLN; [email-masked]
> Cc : Alan DeKok; Stefan Winter; draft-ietf-radext-ip-port-radius-
> [email-masked]
> Objet : RE: Shepherd review of draft-ietf-radext-ip-port-radius-06
> 
> Hi Lionel,
> 
> Thank you very much for your careful review and suggestions along with
> proposed text. We have incorporated all of your comments and posted the
> 07 text.
> 
> Please review and let us know if there is any other comments, and we look
> forward to your submission to IESG.
> 
> Regards
> Draft authors
> 
> > - Sub-attribute type must be defined by encapsulating attributes.
> > There is therefore no unique type. See comment on IANA section.
> >
> > Comment: the CGN does not communicate with the RADIUS server. And
> not
> > sure that it is needed to speak about that here.
> >
> > proposed modification:
> >
> >    RADIUS Protocol Extensions [RFC6929]. It contains the following
> > sub-
> > attributes:
> >    RADIUS Protocol Extensions [RFC6929]. It contains the following
> > sub-
> > attributes:
> >    RADIUS Protocol Extensions [RFC6929]. It contains the following
> > sub-
> > attributes:
> > s/refers to IPFIX Element transportType (TBAx1)/refers to IPFIX
> > Information Element "transportType" (TBAx1) s/contains IPFIX Element
> > transportType/contains the values defined for the IPFIX Information
> > Element "transportType"
> >
> > comment: the same applies for the TLV defined in this document.
> > (section
> > 3.2.1 to 3.2.11)
> >
> > "...which indicates the maximum number of ports for a given IPv4
> > address assigned to a subscriber for a specified IP-Port-Type."
> >
> >
> > ******
> >
> > requirement/ using it. The support of IP port limit is also documented
> > in [RFC6888] as a requirement for CGN.
> >
> > *****
> >
> __________________________________________________________
> ____________
> > _____ ______________________________________________
> >
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete
> > altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Mar 2016 10:51:17 -0500

> What about "IP-Port-Limit-Info" (or something else) for the attribute name? 

  RFC 6929 Section 2.7.1 suggests that names should be globally unique:

   It is therefore RECOMMENDED that specifications give names to
   Attributes that attempt to be globally unique across all RADIUS
   Attributes.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Mar 2016 11:15:46 -0500

>      TBD2.2.  It MUST uniquely refer to the IPFIX Information Element

  I've taken a look at the IANA assignments, and I think some clarification is necessary.

  The ASCII art is problematic, because it shows only the TLV encoding, and not the parent encoding.  Traditionally, the ASCII art showed the *entire* RADIUS attribute, including parent attributes.  See RFC 6929 section 3.1 for an example.

> TB2.2. --> 241.TB2.2

  That's again confusing.  The "241.TBD2.2" name implies that the attribute has type / extended-type / tlv-type.  Yet the ASCII art only shows one "type" field.

  I  suggest using "TLV-Type" instead of "Type" in the ASCII art and associated text, to make it clear that only the TLV portion is being defined here.

  Ideally, also reference the data types draft ((informational), and say you're using the same naming scheme as there.

  I suggest removing the colons after the field names.  It's unusual, and hasn't been done before in RADIUS RFCs.  e.g.

 Type:

 	explanatory text

to:

 TLV-Type

	explanatory text

  There are a *lot* of unnecessary colons in field names.

  For newly created TLVs, it's acceptable to define their numbers in the RFC.  e.g. IIP-Port-Forwarding-Map is defined to carry a number of sub-attributes.  Each of the sub-attributes can have their numbers assigned explicitly, starting at 1.  The definition of each sub-attribute should say that this sub-attribute is contained within the parent attribute.

  I'm not clear on the text for many sub-attributes.  e.g. Section 3.2.1 IP-Port-Type TLV

 Type:

      The value depends on the encapsulating attribute (see IANA
      Section).  This MUST uniquely refer to the IPFIX Information
      Element identifier TBAx1.

  What does that mean?  It's confusing.

  The table in Section 7.3 indicates that the attribute has different TLV-Type values, depending on the parent attribute.  I *STRONGLY* recommend not doing this.  If you're going to have attributes contain similar sub-attributes, there is *no cost* to having the sub-attributes use the same numbers.  It's just good design.

  It also avoids the confusing text noted above.  Instead, we could just have IP-Port-Type TLV say:

TLV-Type

	1

  Which is clear and has no potential for confusion.

  This also makes Section 7.3 simpler.  You can just define the sub-attributes, and tell IANA to allocate those numbers in all of the three parents.  There should be a note that all three parents MUST have identical children.  I don't think there's a reason to do anything else.

  The document should have a comment on globally unique names, and reference RFC 6929 Section 2.7.1.  I think using the same name for sub-attributes here is acceptable.  And it's up to implementors to find a way to reference them uniquely.  This draft should avoid proposing an attribute naming scheme.

  Alan DeKok.

---

From: <[email-masked]>
Date: Fri, 11 Mar 2016 18:24:19 +0000

Hi Alan,

thank you for your review.

Please see below.

regards

Lionel

> De : Alan DeKok [mailto:[email-masked]]
> Envoyé : jeudi 10 mars 2016 17:16
> À : MORAND Lionel IMT/OLN
> Cc : Dean cheng; [email-masked]; Winter Stefan; draft-ietf-radext-ip-port-
> [email-masked]
> Objet : Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06
> 
>   The ASCII art is problematic, because it shows only the TLV encoding, and
> not the parent encoding.  Traditionally, the ASCII art showed the *entire*
> RADIUS attribute, including parent attributes.  See RFC 6929 section 3.1 for an
> example.
> 
> > TB2.2. --> 241.TB2.2
> 
>   That's again confusing.  The "241.TBD2.2" name implies that the attribute
> has type / extended-type / tlv-type.  Yet the ASCII art only shows one "type"
> field.
> 
>   I  suggest using "TLV-Type" instead of "Type" in the ASCII art and associated
> text, to make it clear that only the TLV portion is being defined here.

[LM] Right!

> using the same naming scheme as there.

[LM] OK. Can be done in the introduction of section 3 (true for attribute and TLV)

>   There are a *lot* of unnecessary colons in field names.

[LM] ok

> 
> 
>   For newly created TLVs, it's acceptable to define their numbers in the RFC.
> e.g. IIP-Port-Forwarding-Map is defined to carry a number of sub-attributes.
> Each of the sub-attributes can have their numbers assigned explicitly, starting
> at 1.  The definition of each sub-attribute should say that this sub-attribute is
> contained within the parent attribute.
> 

[LM] TYPE is actually TYPE.EXTENDED-TYPE.TLV-TYPE  here. And as the same TLV can be reused in different attributes, the identifier depends on the TYPE.EXTENDED-TYPE.  
> 
>   The table in Section 7.3 indicates that the attribute has different TLV-Type
> values, depending on the parent attribute.  I *STRONGLY* recommend not
> doing this.  If you're going to have attributes contain similar sub-attributes,
> there is *no cost* to having the sub-attributes use the same numbers.  It's
> just good design.

[LM] not sure to understand/agree. Each TYPE.EXTENDED-TYPE create its own namespace starting by 1 (TYPE.EXTENDED-TYPE.1). Therefore, the number is only significant for a given (parent) attribute. having the same number would work for now. But as soon as a new sub-attribute would be created to be used in the three attributes in the future, it would have automatically the value 4 for the first one, 6 for the second and 8 for the third one.

>   Which is clear and has no potential for confusion.
[LM] see above.

>   This also makes Section 7.3 simpler.  You can just define the sub-attributes,
> and tell IANA to allocate those numbers in all of the three parents.  There
> should be a note that all three parents MUST have identical children.  I don't
> think there's a reason to do anything else.
> 
>   The document should have a comment on globally unique names, and
> reference RFC 6929 Section 2.7.1.  I think using the same name for sub-
> attributes here is acceptable.  And it's up to implementors to find a way to
> reference them uniquely.  This draft should avoid proposing an attribute
> naming scheme.
> 
[LM] As I said, it is not critical. But from a specification point of view, speaking about IP-Port-Limit (attribute or TLV) could be misleading, and drive to misimplementation.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Mar 2016 14:10:01 -0500

> [LM] TYPE is actually TYPE.EXTENDED-TYPE.TLV-TYPE  here. And as the same TLV can be reused in different attributes, the identifier depends on the TYPE.EXTENDED-TYPE.

  My concern is the idea of the "same" TLV.  If it's the same TLV, I would *strongly* prefer using the same TLV-Type value.

> [LM] not sure to understand/agree. Each TYPE.EXTENDED-TYPE create its own namespace starting by 1 (TYPE.EXTENDED-TYPE.1). Therefore, the number is only significant for a given (parent) attribute.

  All true.

> having the same number would work for now. But as soon as a new sub-attribute would be created to be used in the three attributes in the future, it would have automatically the value 4 for the first one, 6 for the second and 8 for the third one.

  Which I find confusing.  As opposed to saying "these 3 parents all contain the same set of TLVs, with the same values".  Any new TLV which gets allocated gets a number.  *One* number.  Instead of 3 different numbers, which depend on the parent.

  There is no reason to try to allocate the minimum number of TLVs.  For me, the benefit of using the same number outweighs any benefit of having a smaller number of TLVs allocated for each parent attribute.

> [LM] As I said, it is not critical. But from a specification point of view, speaking about IP-Port-Limit (attribute or TLV) could be misleading, and drive to misimplementation.

  I agree.  We have two choices here:

1) assign each TLV different TLV-Types, depending on the parent attribute.  In that case, we should just give them different names, too.  That way there's no confusion about which name refers to what TLV-Type.

2) assign each TLV the same TLV-Type, independent of the parent.  In that case, the name can be re-used, because they're just defining a generic TLV.   We'll need some *implementation defined* way of naming the TLV inside of each parent... but that's outside the scope of this draft.  It could recommend using "Parent-Name.TLV-Name", while noting that it doesn't define a standard of any kind.

  I just find it confusing to see attribute "Foo-Bar" defined as having 3 different values for TLV-Type.  Either make them all different and give them different names, or make them the same, and give them the same TLV-Type.

  The half & half solution is worse (for me) than either (1) or (2) above.

  Alan DeKok.

---

From: Dean cheng <[email-masked]>
Date: Tue, 15 Mar 2016 01:42:33 +0000

Hi Alan & Lionel,

Thanks for the comments, and we believe we've
incorporated all please see the 08.txt just 
posted.

For the TLV-Type, we assigned each a value and
a name (please see Section 3.2.1 to 3.2.11 as
well as Section 7.3), but in the description
text of each TLV-section, we also indicated the
TLV's identifier.

E.g. (Section 3.2), the IP-Port-Limit TLV is
identified as 241.TBD1.2.

E.g. (Section 3.1), the IP-Port-Type TLV is
identified as 241.TBD1.1, 241.TBD2.1, or
241.TBD3.1, depending on the containing (parent's)
attribute.

Hope this leads to a compromise.

Regards
Draft authors.

> From: Alan DeKok [mailto:[email-masked]]
> Sent: Friday, March 11, 2016 11:10 AM
> To: [email-masked]
> Cc: Dean cheng; [email-masked]; Winter Stefan; draft-ietf-radext-ip-port-
> Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-
> 06
> 
> > [LM] TYPE is actually TYPE.EXTENDED-TYPE.TLV-TYPE  here. And as the same
> TLV can be reused in different attributes, the identifier depends on the
> TYPE.EXTENDED-TYPE.
> 
>   My concern is the idea of the "same" TLV.  If it's the same TLV, I would
> *strongly* prefer using the same TLV-Type value.
> 
> >>  The table in Section 7.3 indicates that the attribute has different
> >> TLV-Type values, depending on the parent attribute.  I *STRONGLY*
> >> recommend not doing this.  If you're going to have attributes contain
> >> similar sub-attributes, there is *no cost* to having the
> >> sub-attributes use the same numbers.  It's just good design.
> >
> > [LM] not sure to understand/agree. Each TYPE.EXTENDED-TYPE create its own
> namespace starting by 1 (TYPE.EXTENDED-TYPE.1). Therefore, the number is
> only significant for a given (parent) attribute.
> 
>   All true.
> 
> > having the same number would work for now. But as soon as a new sub-
> attribute would be created to be used in the three attributes in the future,
> it would have automatically the value 4 for the first one, 6 for the second
> and 8 for the third one.
> 
>   Which I find confusing.  As opposed to saying "these 3 parents all
> contain the same set of TLVs, with the same values".  Any new TLV which
> gets allocated gets a number.  *One* number.  Instead of 3 different
> numbers, which depend on the parent.
> 
>   There is no reason to try to allocate the minimum number of TLVs.  For me,
> the benefit of using the same number outweighs any benefit of having a
> smaller number of TLVs allocated for each parent attribute.
> 
> >> reference RFC 6929 Section 2.7.1.  I think using the same name for
> >> sub- attributes here is acceptable.  And it's up to implementors to
> >> find a way to reference them uniquely.  This draft should avoid
> >> proposing an attribute naming scheme.
> >>
> > [LM] As I said, it is not critical. But from a specification point of
> view, speaking about IP-Port-Limit (attribute or TLV) could be misleading,
> and drive to misimplementation.
> 
> 1) assign each TLV different TLV-Types, depending on the parent attribute.
> In that case, we should just give them different names, too.  That way
> there's no confusion about which name refers to what TLV-Type.
> 
> 2) assign each TLV the same TLV-Type, independent of the parent.  In that
> case, the name can be re-used, because they're just defining a generic TLV.
> We'll need some *implementation defined* way of naming the TLV inside of
> each parent... but that's outside the scope of this draft.  It could
> recommend using "Parent-Name.TLV-Name", while noting that it doesn't define
> a standard of any kind.
> 
>   I just find it confusing to see attribute "Foo-Bar" defined as having 3
> different values for TLV-Type.  Either make them all different and give
> them different names, or make them the same, and give them the same TLV-
> Type.
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Mar 2016 13:19:15 -0400

> text of each TLV-section, we also indicated the

  That's good.

  I'd also suggest adding a note in Section 3.2 that the TLVs the same numbering, for simplicity.

from:

   The TLVs that are included in the three attributes (see Section 3.1)
   are defined in the following sub-sections.  These TLVs use the format
   defined in [RFC6929].

to:

   The TLVs that are included in the three attributes (see Section 3.1)
   are defined in the following sub-sections.  These TLVs use the format
   defined in [RFC6929].   As the three attributes carry similar data,
   we have defined a common set of TLVs which are used for all three
   attributes.  That is, the TLVs have the same name and number,
   when encapsulated in any one of the three parent attributes.  See
   Sections 3.1.1, 3.1.2, and 3.1.3 for a list of which TLV is permitted
   within which parent attribute.

Section 3.2.1 has:

TLV-Type

   1.  This MUST uniquely refer to the IPFIX Information Element
      identifier TBAx1.

  I suggest moving the explanatory sentence elsewhere, such as the Description field.  The TLV-Type content should just be a single digit "1".

  Similar comments apply to the other TLVs.

3.2.2.  IP-Port-Limit TLV

Length

    6.

 I suggest removing the "." for consistency.

The description fields for TLVs have text like:

   ... Its "Type"
   field contains a value that uniquely refers to IPFIX Information
   Element natEvent (230),  and its "Value" field contains IPFIX
   Information Element "natEvent", which is a flag to indicate an action
   of NAT operation (refer to [IPFIX]).

I suggest updating that to:

   This attribute carries IPFIX Information Element 230, "natEvent",
   which is a flag to indicate an action
   of NAT operation (refer to [IPFIX]).

  I think my comments are little more than nit picks and minor clarifications at this point. :)

---

From: <[email-masked]>
Date: Wed, 16 Mar 2016 18:07:11 +0000

Hi,

I think that there is still an issue regarding the value allocated for sub-attributes. As per RFC6929, they have to be allocated per attribute and not globally. 

About the naming issue, I would suggest to follow the example of the Extended-Vendor-Specific, that could be seen as the "same" attribute but defined in different type codes, with the name being suffixed by a digit (e.g.  Extended-Vendor-Specific-1 for 24.126, Extended-Vendor-Specific-2 for 242.26, etc.). I would propose to reuse the same logic for sub-attributes reused inside multiple attributes, e.g. IP-Port-Type-1 in the first attribute, IP-Port-Type-2 in the second attribute, etc.

Following the guidelines given section 6.7 of RFC6929, I think that it will be easier to define the sub-attribute in the section defining the attribute (instead of having standalone section for attributes and Sub-attributes).

New proposed table of contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Extended Attributes for IP Ports . . . . . . . . . .   5
     3.1.  IP-Port-Limit-Info Attribute  . . . . . . . . . . . .   6
       3.1.1.  Definition and Format  . . . . . . . . . . . .   6
       3.1.2.  Sub-attributes . . . . . . . . . . . . . . .   8
         3.1.2.1  IP-Port-Type-1. . . . . . . . . .  10
         3.1.2.2  IP-Port-Limit. . . . . . . . . .  10
         3.1.2.3  IP-Port-Ext-IPv4-Addr-1. . . . . . . . . .  10
     3.2.  IP-Port-Range Attribute. . . . . . . . . . . . . . . .  13
       3.2.1.  Definition and Format  . . . . . . . . . . . .   6
       3.2.2.  Sub-attributes . . . . . . . . . . . . . . .   8
         3.2.2.1  IP-Port-Type-2. . . . . . . . . .  10
         3.2.2.2  IP-Port-Ext-IPv4-Addr-2. . . . . . . . . .  10 
         3.2.2.3  IP-Port-Local-Id-1. . . . . . . . . .  10 
         3.2.2.4  IP-Port-Range-Start. . . . . . . . . .  10
         3.2.2.5  IP-Port-Range-End. . . . . . . . . .  10
         3.2.2.6  IP-Port-Alloc. . . . . . . . . .  10
     3.3.  IP-Port-Forwarding-Map  Attribute  . . . . . . . . . . . . . . . .  13
       3.3.1.  Definition and Format  . . . . . . . . . . . .   6
       3.3.2.  Sub-attributes . . . . . . . . . . . . . . .   8
         3.3.2.1  IP-Port-Type-3. . . . . . . . . .  10
         3.3.2.2  IP-Port-Ext-IPv4-Addr-3. . . . . . . . . .  10
         3.3.2.3  IP-Port-Local-Id-2. . . . . . . . . .  10
         3.3.2.4  IP-Port-Int-IPv4-Addr. . . . . . . . . .  10
         3.3.2.5  IP-Port-Int-IPv6-Addr. . . . . . . . . .  10
         3.3.2.6  IP-Port-Int-Port. . . . . . . . . .  10
         3.3.2.7  IP-Port-Ext-Port. . . . . . . . . .  10
   4.  Applications, Use Cases and Examples  . . . . . . . . . . . .  23
     4.1.  Managing CGN Port Behavior using RADIUS . . . . . . . . .  23
       4.1.1.  Configure IP Port Limit for a User  . . . . . . . . .  24
       4.1.2.  Report IP Port Allocation/Deallocation  . . . . . . .  26
       4.1.3.  Configure Forwarding Port Mapping . . . . . . . . . .  27
       4.1.4.  An Example  . . . . . . . . . . . . . . . . . . . . .  29
     4.2.  Report Assigned Port Set for a Visiting UE  . . . . . . .  30
   5.  Table of Attributes . . . . . . . . . . . . . . . . . . . . .  31
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  32
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32
     7.1.  IANA Considerations on New IPFIX Information Elements . .  32
     7.2.  IANA Considerations on New RADIUS Attributes  . . . . . .  33
     7.3.  IANA Considerations on New RADIUS Nested Attributes . . .  33
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  34
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  34
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

In the section 7.3, I would then go back to the proposed approach given in version -07:

7.3.  IANA Considerations on New RADIUS Sub-attributes

   This specification requests allocation of the following sub-attributes within
   the attribute IP-Port-Limit-Info 241.TBD1:

      Identifier          Name                   Meaning
      --------------      --------------                   -------
      241.TBD1.1      IP-Port-Type          see Section 3.2.1
      241.TBD1.2      IP-Port-Limit         see Section 3.2.2
      241.TBD1.3      IP-Port-Ext-IPv4-Addr see Section 3.2.3
     241. TBD1.{4-253}	Unassigned
     245. TBD1.{254-255}	Reserved

   This specification requests allocation of the following sub-attributes within
   the attribute IP-Port-Range 241.TBD2:

      Identifier       Name                   Meaning
      ----       ----                   -------
      241.TBD2.1      IP-Port-Type-1          see Section 3.2.1
      241.TBD2.2      IP-Port-Ext-IPv4-Addr-1 see Section 3.2.3
      241.TBD2.3      IP-Port-Local-Id-1      see Section 3.2.11
      241.TBD2.4      IP-Port-Alloc         see Section 3.2.8
      241.TBD2.5      IP-Port-Range-Start   see Section 3.2.9
      241.TBD2.6      IP-Port-Range-End     see Section 3.2.10
     241. TBD2.{7-253}	Unassigned
     245. TBD2.{254-255}	Reserved

   This specification requests allocation of the following sub-attributes within
   the attribute IP-Port-Forwarding-Map 241.TBD3:

      Type       Name                   Meaning
      ----       ----                   -------
      241.TBD3.1      IP-Port-Type-2          see Section 3.2.1
      241.TBD3.2      IP-Port-Ext-IPv4-Addr-2 see Section 3.2.3
      241.TBD3.3      IP-Port-Local-Id-1      see Section 3.2.11
      241.TBD3.4      IP-Port-Int-IPv4-Addr see Section 3.2.4
      241.TBD3.5      IP-Port-Int-IPv6-Addr see Section 3.2.5
      241.TBD3.6      IP-Port-Int-Port      see Section 3.2.6
      241.TBD3.7      IP-Port-Ext-Port      see Section 3.2.7
     241. TBD3.{8-253}	Unassigned
     245. TBD3.{254-255}	Reserved

To try to persuade you that the proposed is the best one, here is an "example" of what would look like after the Radius Attribute Types registry after publication of the new RFC.

241			Extended-Attribute-1		[RFC6929]
241.1			Frag-Status			[RFC7499]
241.2			Proxy-State-Length		[RFC7499]

241.3			IP-Port-Limit-Info		NEW RFC
241.3.1			IP-Port-Type-1			NEW RFC
241.3.2			IP-Port-Ext-IPv4-Addr-1	NEW RFC
241.3.3			IP-Port-Limit			NEW RFC
241.3.{4-253}		Unassigned			NEW RFC
245.3.{254-255}	Reserved			NEW RFC

241.4			IP-Port-Range			NEW RFC
241.4.1			IP-Port-Type-2			NEW RFC
241.4.2			IP-Port-Ext-IPv4-Addr-2 	NEW RFC
241.4.3			IP-Port-Local-Id-1		NEW RFC
241.4.4			IP-Port-Alloc			NEW RFC
241.4.5			IP-Port-Range-Start		NEW RFC
241.4.6			IP-Port-Range-End		NEW RFC
241.4.{7-253}		Unassigned			NEW RFC
245.4.{254-255}	Reserved			NEW RFC

241.5			IP-Port-Forwarding-Map	NEW RFC
241.5.1			IP-Port-Type-3			NEW RFC
241.5.2			IPort-Ext-IPv4-Addr-3		NEW RFC
241.5.3			IP-Port-Local-Id-2		NEW RFC
241.5.4			IP-Port-Int-IPv4-Addr		NEW RFC
241.5.5			IP-Port-Int-IPv6-Addr		NEW RFC
241.5.6			IP-Port-Int-Port		NEW RFC
241.5.7			IP-Port-Ext-Port		NEW RFC
241.5.{8-253}		Unassigned			NEW RFC
245.5.{254-255}	Reserved			NEW RFC

241.{6-25}		Unassigned	
241.26			Extended-Vendor-Specific-1	[RFC6929]
241.{27-240}		Unassigned	
241.{241-255}		Reserved			[RFC6929]

I don't see how using a unique value for sub-attributes would fit in this registry.

I hope that this clarifies my point.

Regards,

Lionel

> De : radext [mailto:[email-masked]] De la part de Dean cheng
> Envoyé : mardi 15 mars 2016 02:43
> À : Alan DeKok; MORAND Lionel IMT/OLN
> Cc : [email-masked]; [email-masked];
> Winter Stefan
> Thanks for the comments, and we believe we've incorporated all please see
> the 08.txt just posted.
> 
> For the TLV-Type, we assigned each a value and a name (please see Section
> 3.2.1 to 3.2.11 as well as Section 7.3), but in the description text of each TLV-
> section, we also indicated the TLV's identifier.
> 
> E.g. (Section 3.2), the IP-Port-Limit TLV is identified as 241.TBD1.2.
> 
> E.g. (Section 3.1), the IP-Port-Type TLV is identified as 241.TBD1.1,
> 241.TBD2.1, or 241.TBD3.1, depending on the containing (parent's) attribute.
> 
> > Cc: Dean cheng; [email-masked]; Winter Stefan;
> > draft-ietf-radext-ip-port- [email-masked]
> > TLV can be reused in different attributes, the identifier depends on
> > the TYPE.EXTENDED-TYPE.
> >
> > >>  The table in Section 7.3 indicates that the attribute has
> > >> different TLV-Type values, depending on the parent attribute.  I
> > >> *STRONGLY* recommend not doing this.  If you're going to have
> > >> attributes contain similar sub-attributes, there is *no cost* to
> > >> having the sub-attributes use the same numbers.  It's just good design.
> > >
> > namespace starting by 1 (TYPE.EXTENDED-TYPE.1). Therefore, the number
> > is only significant for a given (parent) attribute.
> >
> >   All true.
> >
> > attribute would be created to be used in the three attributes in the
> > future, it would have automatically the value 4 for the first one, 6
> > for the second and 8 for the third one.
> >
> > contain the same set of TLVs, with the same values".  Any new TLV
> > which gets allocated gets a number.  *One* number.  Instead of 3
> > different numbers, which depend on the parent.
> >
> >   There is no reason to try to allocate the minimum number of TLVs.
> > For me, the benefit of using the same number outweighs any benefit of
> > having a smaller number of TLVs allocated for each parent attribute.
> >
> > view, speaking about IP-Port-Limit (attribute or TLV) could be
> > misleading, and drive to misimplementation.
> >
> > 2) assign each TLV the same TLV-Type, independent of the parent.  In
> > that case, the name can be re-used, because they're just defining a generic
> TLV.
> > We'll need some *implementation defined* way of naming the TLV inside
> > of each parent... but that's outside the scope of this draft.  It
> > could recommend using "Parent-Name.TLV-Name", while noting that it
> > doesn't define a standard of any kind.
> >
> >   I just find it confusing to see attribute "Foo-Bar" defined as
> > having 3 different values for TLV-Type.  Either make them all
> > different and give them different names, or make them the same, and
> > give them the same TLV- Type.
> >
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Mar 2016 15:15:27 -0400

> I think that there is still an issue regarding the value allocated for sub-attributes. As per RFC6929, they have to be allocated per attribute and not globally.

  Which section says that?  Section 2 talks about TLV with TLV-Type "1" is not the same as User-Name with Type "1".  But I don't see any restriction on TLV re-use.

  So long as the specification is clear, I think it's OK.

> About the naming issue, I would suggest to follow the example of the Extended-Vendor-Specific, that could be seen as the "same" attribute but defined in different type codes, with the name being su…

  I understand... it just seems awkward to me.

  Alan DeKok.

---

From: <[email-masked]>
Date: Wed, 16 Mar 2016 19:30:51 +0000

Hi Alan,

I think that you can check the section 10.3.6:

10.3.6<http://tools.ietf.org/html/rfc6929#section-10.3.6>. Allocation within a TLV
   Specifications can request allocation of Attribute Type values within
   an Attribute of data type TLV.  The encapsulating TLV can be
   allocated in the same specification, or it can have been previously
   allocated.

   Specifications need to request allocation within a specific Attribute
   Type value (e.g., "TYPE.TLV.*").  Allocations are performed from the
   smallest Unassigned value, proceeding to the largest Unassigned
   value.

Regards,

Lionel

Envoyé depuis Surface

De : Alan DeKok<mailto:[email-masked]>
Envoyé : ‎mercredi‎ ‎16‎ ‎mars‎ ‎2016 ‎20‎:‎15
À : Lionel MORAND<mailto:[email-masked]>
Cc : Dean cheng<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, Winter Stefan<mailto:[email-masked]>

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Mar 2016 15:35:40 -0400

> I think that you can check the section 10.3.6:

  Sure.  That doesn't forbid using similar allocations in different parent attributes.

  Alan DeKok.

---

From: <[email-masked]>
Date: Wed, 16 Mar 2016 20:04:32 +0000

It is what I have try to do, putting IP-Port-Type, IP-Port-Ext-IPv4-Addr at the first places but it does not fly when considering IP-Port-Local-Id that is defined only in two of the three attibutes.

If you consider the RADIUS attribute types registry, what would be your counter-proposal?

lionel

Envoyé depuis Surface

De : Alan DeKok<mailto:[email-masked]>
Envoyé : ‎mercredi‎ ‎16‎ ‎mars‎ ‎2016 ‎20‎:‎35
À : Lionel MORAND<mailto:[email-masked]>
Cc : Dean cheng<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, Winter Stefan<mailto:[email-masked]>

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Mar 2016 16:08:32 -0400

On Mar 16, 2016, at 4:04 PM, <[email-masked]> <[email-masked]> wrote:
> 
> It is what I have try to do, putting IP-Port-Type, IP-Port-Ext-IPv4-Addr at the first places but it does not fly when considering IP-Port-Local-Id that is defined only in two of the three attributes.

  There's no perfect solution.  If there was one, we'd be using Diameter, not RADIUS. :)

  In this case, the main push from me is that a TLV called "foo" should have the same TLV-Type value (e.g. 1) across multiple parent TLVs.  There is enough space to do sparse allocation.  And it would be confusing to see a dictionary like:

ATTRIBUTE   TLV-IP-Port-1  2
ATTRIBUTE   TLV-IP-Port-2  5
ATTRIBUTE   TLV-IP-Port-3  9

  With all of them having the same meaning, but different parent attributes... and different TLV-Type values.

  It would be less confusing to have them all as the same value.

> If you consider the RADIUS attribute types registry, what would be your counter-proposal?

  Sparse allocation is fine.

  Alan DeKok.

---

From: <[email-masked]>
Date: Thu, 17 Mar 2016 09:31:11 +0000

Hi Alan,

I know that it is not a perfect solution but having fixed values for sub-TLV used in any attribute would mean that it would be possible to define only 253 sub-TLVs as there would be independent of the parent attributes. And it will be a nightmare for IANA allocation as you will have to put as reserved values for the parent attributes not using the sub-TLV. Any allocation of a new code for a sub-TLV will have impact on all the other TLV attributes as the allocated value will be reserved for this new sub-TLV.

Following the rule that any attribute will define its own space, you can define up to 253 per parent attribute, even if the counterpart is that the same "attribute" may have different identifiers and names if reused in multiple attributes.

As you said, it would different if we had a flat code value range with enough values to allocate unique number for sub-TLV, as with Diameter. But we have to face with the existing constraints in RADIUS and I think that the extra-complexity to manage the same TLV with different name/id is acceptable regarding the extensibility introduced in RADIUS with the definition of the extended attributes types.

Regards,

Lionel

> Envoyé : mercredi 16 mars 2016 21:09
> Cc : Dean cheng; [email-masked]; draft-ietf-radext-ip-port-radius-
> [email-masked]; Winter Stefan
> > It is what I have try to do, putting IP-Port-Type, IP-Port-Ext-IPv4-Addr at
> the first places but it does not fly when considering IP-Port-Local-Id that is
> defined only in two of the three attributes.
> 
>   In this case, the main push from me is that a TLV called "foo" should have
> the same TLV-Type value (e.g. 1) across multiple parent TLVs.  There is
> enough space to do sparse allocation.  And it would be confusing to see a
> dictionary like:
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Mar 2016 08:52:26 -0400

I think Alan has an important point here.
I think it would be worth some time looking at sharing namespaces for
TLVs.
I think this issue is worth a bit of exploration.

In more formal language, Alan has raised a technical objection that it
would be desirable to share namespaces for implementation simplicity.
Lionel has raised an objection that creates administrative complexity.

I don't think either of these has been adequately explored, and so I
think it is worth the WG's time to explore.

---

From: <[email-masked]>
Date: Thu, 17 Mar 2016 13:10:41 +0000

Hi Sam,

I agree.

A time slot has been already reserved for discussion on the draft-ietf-radext-ip-port-radius at the next IETF meeting.
We could either use this slot to go on this discussion during the meeting or have a specific slot for this topic.

Any additional feedback is welcome on the mailing list before the meeting.

Regards,

Lionel

> De : Sam Hartman [mailto:[email-masked]]
> Envoyé : jeudi 17 mars 2016 13:52
> Cc : Alan DeKok; Dean cheng; [email-masked]; Winter Stefan; draft-ietf-
> [email-masked]
> I think it would be worth some time looking at sharing namespaces for TLVs.
> In more formal language, Alan has raised a technical objection that it would
> be desirable to share namespaces for implementation simplicity.
> I don't think either of these has been adequately explored, and so I think it is
> worth the WG's time to explore.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 17 Mar 2016 14:36:49 +0100

Hi,

> think it is worth the WG's time to explore.

Not only has it not been explored: any such procedures would have to be
documented for IANA so that they know to reserve integers the right way.
Or are we aiming low and only want a shared namespace for *this* RFC?

This indeed looks like something worth discussing. We had already
reserved 5 min for this draft but that was when the thread only just
started ;-)

At this point it's probably better to reserve 10 min to allow for good
discussion. I'm updating the agenda.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Stefan Winter <[email-masked]>
Date: Thu, 17 Mar 2016 15:02:26 +0100

Hello,

> ATTRIBUTE   TLV-IP-Port-3  9

The question is, how many people really read dictionaries? As in, do
people really care about the wire format, so that it is worth the effort
to make it look more pretty?

If the only ones confused are those *writing* the dictionaries then I
would think: too bad; just get it right once.

I for one never took offence that Access-* packet types occupy 1,2,3 and
11; with Accounting-* breaking the sequence with 4 and 5. And a big hole
afterwards. Even though they logically belong together. - They are just
integers. (Yes, I'm aware that the analogy doesn't carry very far.)

If in return we get easier manageability by IANA, I would be prepared to
live with this minimal ugliness.

YPMV (... perception ...)

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Mar 2016 11:03:29 -0400

> to make it look more pretty?

  It's less that, than consistency.  If we have multiple attributes all containing the same data, then the data should, well... be the same.

  Diameter has "Group", which can contain arbitrary attributes, so it doesn't have this problem.  RADIUS doesn't have the concept of grouped attributes.

> would think: too bad; just get it right once.

  If it was just dictionaries, sure.  It's also a management problem.  If 3 parent attributes contain the same set of TLVs, what happens when you add a new TLV?  i.e. one which is supposed to be carried in all parents?

a) define it once, and say "it can exist in all 3 parents"

b) define it three times, with three different names and three different TLV-Type values... but one meaning.

  I lean towards (a).  I see it as being marginally better than (b). 

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Mar 2016 11:07:33 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    >> TLV-IP-Port-3 9

    Stefan> The question is, how many people really read dictionaries?
    Stefan> As in, do people really care about the wire format, so that
    Stefan> it is worth the effort to make it look more pretty?

I think Alan's point is that if you use the same numbering you can get
it down to tlv-ip-port without a suffix number.

The issue here is that for some implementations, the tlv name is
globally unique not unique within the scope of an attribute.
So, by using different allocations, for these implementations we're
specifically requiring people to be more aware of the wire format than
they'd like to be.

Alan, have I got that right?

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Mar 2016 11:58:55 -0400

> it down to tlv-ip-port without a suffix number.

  That, too.

> Alan, have I got that right?

  Yes.

   Alan DeKok.

---

From: Dean cheng <[email-masked]>
Date: Fri, 18 Mar 2016 00:24:33 +0000

Thanks Alan, and we just updated the draft accordingly
and uploaded as 09.txt.

We will review comments from Lionel, and hopefully
we'll have a consensus on how to deal with TLV
value assignment in Radius protocol.

Regards
Dean

> Sent: Wednesday, March 16, 2016 10:19 AM
> To: Dean cheng
> Cc: [email-masked]; [email-masked]; draft-ietf-radext-ip-port-
> [email-masked]; Winter Stefan
> > For the TLV-Type, we assigned each a value and a name (please see
> > Section 3.2.1 to 3.2.11 as well as Section 7.3), but in the
> > description text of each TLV-section, we also indicated the TLV's
> > identifier.
> 
>   That's good.
> 
>   I suggest moving the explanatory sentence elsewhere, such as the
> Description field.  The TLV-Type content should just be a single digit "1".
>