Re: [radext] 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

> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: Tuesday, March 01, 2016 9:23 AM
> To: radext@ietf.org
> Cc: Alan DeKok; Stefan Winter; draft-ietf-radext-ip-port-radius-
> ext.authors@ietf.org
> 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.
> 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.