From nobody Tue Mar 1 09:23:41 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5B81B3023; Tue, 1 Mar 2016 09:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D0p0unLwpkn; Tue, 1 Mar 2016 09:23:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909B81B3019; Tue, 1 Mar 2016 09:23:30 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D04873B43B9; Tue, 1 Mar 2016 18:23:28 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.19]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A3C494C072; Tue, 1 Mar 2016 18:23:28 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%19]) with mapi id 14.03.0279.002; Tue, 1 Mar 2016 18:23:28 +0100 From: To: "radext@ietf.org" Thread-Topic: Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSg== Date: Tue, 1 Mar 2016 17:23:27 +0000 Message-ID: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.8.153315 Archived-At: Cc: Stefan Winter , Alan DeKok , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:23:38 -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 draf= t 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 requi= red. 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."=20 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 collocate= d 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=20 will populate the user's configuration information to the Network=20 Access Server (NAS), which is often referred to as a Broadband=20 Network Gateway (BNG) in broadband access networks.=20 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 ma= pping=20 behavior applied by the CGN to a user session to the RADIUS server, as p= art of the=20 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=20 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=20 mapping or ICMP identifier mapping as required. =20 ******** "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 mod= el. 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=20 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) [RFC688= 7], 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 th= e=20 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 s= ections. 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=20 RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attr= ibutes: - an IP-Port-Type TLV (see section 3.2.1),=20 - 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=20 number of IP ports indicated by the device supporting port ranges=20 co-allocated with the NAS e.g. a CGN or NAT64. However, the RADIUS=20 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=20 RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attr= ibutes: - 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 corr= ect Proposed change: This attribute is of type "TLV" as defined in the=20 RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attr= ibutes: - 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=20 IP-Port-Local-Id TLV (see section 3.2.11),=20 - either an IP-Port-Int-IPv6-Addr TLV (see section 3.2.5) or an=20 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)=20 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 as= signed 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.=20 s/BNG hosts the NAS/BNG acts as a NAS ***** A CGN function in a broadband network would most likely reside on a BNG.=20=20 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 requirem= ent/ 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 B= NG, acting as a NAS and collocated with the CGN, using a new RADIUS attribut= e=20 called IP-Port-Limit (defined in Section 3.1.1), along with other config= uration 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 the= ses 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=20 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=20 ***** 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=20 ***** 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=20 ****** 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"=20 (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=20 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Mon Mar 7 08:01:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01F81B4331 for ; Mon, 7 Mar 2016 08:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xRmJDE9elbK for ; Mon, 7 Mar 2016 08:01:11 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBE31B4352 for ; Mon, 7 Mar 2016 08:01:10 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id CE11F43ADF for ; Mon, 7 Mar 2016 17:01:08 +0100 (CET) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56DDA5C4.7000403@restena.lu> Date: Mon, 7 Mar 2016 17:01:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vVUK93dQ2MLVhrVit0fNJkIBcKHqt0miB" Archived-At: Subject: [radext] Preliminary Agenda & Call for agenda items X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:01:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vVUK93dQ2MLVhrVit0fNJkIBcKHqt0miB Content-Type: multipart/mixed; boundary="iQKDDCoxhv8nb14m3RFxgDf4MMTViJ9cq" From: Stefan Winter To: "radext@ietf.org" Message-ID: <56DDA5C4.7000403@restena.lu> Subject: Preliminary Agenda & Call for agenda items --iQKDDCoxhv8nb14m3RFxgDf4MMTViJ9cq Content-Type: multipart/mixed; boundary="------------080808050408010202040001" This is a multi-part message in MIME format. --------------080808050408010202040001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, earlier today, the preliminary agenda for IETF95 has been published. We are the ones who turn the lights off this time - we have the very last slot on Friday afternoon (1220-1320). We hope you can still be there and aren't already in transit back $HOME. Please let the list know if you plan to present at the meeting. We will collect all requests for agenda items and create a detailed agenda for radext soon. Greetings, Stefan & Lionel --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------080808050408010202040001 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------080808050408010202040001-- --iQKDDCoxhv8nb14m3RFxgDf4MMTViJ9cq-- --vVUK93dQ2MLVhrVit0fNJkIBcKHqt0miB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW3aXEAAoJEMDeajWKOdxm3b4P/3eSkEP0/mRr5avspHs1uqYQ 3ZOvlZ6Rg9vhn1sDkT2gEz3zEFDd+PmOOvJEHGeHKueJ8o3LK85HiRyKBqu9w0B3 G0EWVCu7jeavqLMi9A9Jwn3vHiC4d5IBQT94JlwuZzz8qyC7uj2BVfH0RDeUdTRs tzdPOzlM614G8s5f+gyX72ukw8E8QBx2is3qe2N6PSXXHFAq/0tUOEAXGQh0dt6J 8Olho91URs1jjldmGHVvE/xywBtD5KILuqj5N8RzFeh0BSQWldaqd4OAgjFlr8DN QHFMMAaqZkiU5vwIh7ydclSPuEGSnksFBbAtDtqnsGBYo7E0YhOZCr6Fx0+iwrZN X1H7PCc5hxOikrk2lB0QWxSbupemsnlBbi0TLCRhWyHe0QSbWU+RN+JN277LOeOt bYoxea9bzrCrvmaxo2zKguZcfUlAQ2w6mM1fSPcMXdDPG6KMX68+QfuC3dPTGOHF 6TUEncZvLFFPCX5g4ZoIrrZjmdOXF5zCXp9E2NnAvudaoajpeIS/O8yacOLCYXyh t9E0hnARntK7XeCgVHmstakjVTCa/yDnf9jP9WyEMW5DiIulUbUQ4T0EDHrF73ZM 70Kxa1mcvrF6b7PyzdfM1nwsQTXGGZvba+AQTiR9ddkS9Egh1BWP2ODOdORpIbFa /5GescHFCJS6o1Q4qFQz =itpA -----END PGP SIGNATURE----- --vVUK93dQ2MLVhrVit0fNJkIBcKHqt0miB-- From nobody Tue Mar 8 08:35:07 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10C12D80E for ; Tue, 8 Mar 2016 08:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzUQBEfPl_Al for ; Tue, 8 Mar 2016 08:35:04 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2084C12D7FB for ; Tue, 8 Mar 2016 08:35:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 08004C9E; Tue, 8 Mar 2016 16:35:03 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-34urgEZvQI; Tue, 8 Mar 2016 16:35:02 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 8B8F0A99; Tue, 8 Mar 2016 16:35:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56DDA5C4.7000403@restena.lu> Date: Tue, 8 Mar 2016 11:35:04 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <56DDA5C4.7000403@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Preliminary Agenda & Call for agenda items X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:35:07 -0000 On Mar 7, 2016, at 11:01 AM, Stefan Winter wrote: > We are the ones who turn the lights off this time - we have the very > last slot on Friday afternoon (1220-1320). > > We hope you can still be there and aren't already in transit back $HOME. > > Please let the list know if you plan to present at the meeting. We will > collect all requests for agenda items and create a detailed agenda for > radext soon. I think we should have a discussion on open issues with the CoA draft. Alan DeKok. From nobody Wed Mar 9 02:12:04 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3905A12D5B5 for ; Wed, 9 Mar 2016 02:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBWJUY_n7LBc for ; Wed, 9 Mar 2016 02:12:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A5E12D5AC for ; Wed, 9 Mar 2016 02:12:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6DD3FBE7D for ; Wed, 9 Mar 2016 10:11:59 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joDVMwl9es4g for ; Wed, 9 Mar 2016 10:11:59 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCB1BBE54 for ; Wed, 9 Mar 2016 10:11:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457518319; bh=qzwDUtUqGlR4N2ZkjXGQhQ6U5cNu405fa/TMF89djtI=; h=To:From:Subject:Date:From; b=qGfJnzlMkNxlqY9e/pWCqtD1FUSUyaJebC2DTqyDIHPmnJ2HmC1qjX10o6HpHBEo8 LxBBbmwSepDlZ3UJLil1B25l7imsuu5U7ipC0vgnlwtfYMCitslLNnJwoLbzIaGDW1 s21pp1/JqIMm8HjY3EittLxhyQJHpq9YQe1dcekk= To: radext@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56DFF6EE.9080607@cs.tcd.ie> Date: Wed, 9 Mar 2016 10:11:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010504030907050604010709" Archived-At: Subject: [radext] (very temporary) AD review of draft-ietf-radext-bigger-packets-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 10:12:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010504030907050604010709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Stefan asked if I could help process this while Kathleen is still on leave. So I read it and it seems fine to me, I've only one nit. I'll start IETF LC for this momentarily, My nit: 3.1 says: "a server SHOULD not" - that'd be better as "a server SHOULD NOT" I guess. Cheers, S. --------------ms010504030907050604010709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMDkx MDExNThaMC8GCSqGSIb3DQEJBDEiBCBgh+Uym1W4RnbBFU4/J0RdBE4QPPomLEx0+OdqQzW2 fzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBkV1fdh4iaIkDOhMndd7GXZZiSXFQ+A9/rDONZqiXnuxHCEkgpNvYG 8qO/YmcZwIUbDWfaVzwtoDxqYbnPYwu68CPvIIgfxfrn3WXNqi3PwAJR6tjM+z7/iSGKwV7d kYRNjHSxefqYjHVHDjQ4wVMl8hki4VSnNoKpXosc0S65chc7lEhfRMKWfX2hM5VYvzmxaNF8 Og+6Jh5q1Kl1obxrdMJis/HpW8RPY19RhQlekFgfSr+Rt7awld4WYkZXmXQ8fgV2QGd2Hsqu vvmomR46OzPNeN7DlCaPdCxvOH1VfgFq/trIcoeR26cg1OVeP1ngosPtieOgqJjI8aChsmC7 AAAAAAAA --------------ms010504030907050604010709-- From nobody Wed Mar 9 05:46:17 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ADB12D6A2; Wed, 9 Mar 2016 05:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPR9dTuf14uP; Wed, 9 Mar 2016 05:46:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43C512D535; Wed, 9 Mar 2016 05:46:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0A8293385BC; Wed, 9 Mar 2016 14:46:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D9E844C063; Wed, 9 Mar 2016 14:46:10 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Wed, 9 Mar 2016 14:46:07 +0100 From: To: "multipathtcp@ietf.org" , "radext@ietf.org" Thread-Topic: draft-boucadair-mptcp-radius Thread-Index: AdF6CgdrsXY8B0dZTfqV33XW0DaeKw== Date: Wed, 9 Mar 2016 13:46:07 +0000 Message-ID: <8fa24932-7464-4afd-bf30-5f432060f250@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_8fa2493274644afdbf305f432060f250OPEXCLILM34corporateadr_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.9.133316 Archived-At: Cc: JACQUENET Christian IMT/OLN Subject: [radext] draft-boucadair-mptcp-radius X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 13:46:15 -0000 --_000_8fa2493274644afdbf305f432060f250OPEXCLILM34corporateadr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Comments about this draft (https://tools.ietf.org/html/draft-boucadair-mptc= p-radius-01) are more than welcome. The design follows the recommendations in I-D.ietf-radext-datatypes. Abstract One of the promising deployment scenarios for Multipath TCP (MPTCP) is to enable a Customer Premises Equipment (CPE) that is connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its network attachments. Because of the lack of MPTCP support at the server side, some service providers consider a network-assisted model that relies upon the activation of a dedicated function called: MPTCP Concentrator. This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that allow CPE devices to reach one or multiple MPTCP Concentrators. Thank you. Cheers, Med --_000_8fa2493274644afdbf305f432060f250OPEXCLILM34corporateadr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Comments about this draft (https://tools.ietf.org/html/draft-boucadair-mptcp-radius-01) are more than welcome.

 

The design follows the recommendations in =
I-D.ietf-radext-datatypes.

 

Abstract=

 

   One of= the promising deployment scenarios for Multipath TCP (MPTCP)

   is to = enable a Customer Premises Equipment (CPE) that is connected to<= /span>

   multip= le networks (e.g., DSL, LTE, WLAN) to optimize the usage of its<= /span>

   networ= k attachments.  Because of the lack of MPTCP support at the=

   server= side, some service providers consider a network-assisted model<= /span>

   that r= elies upon the activation of a dedicated function called: MPTCP<= /span>

   Concen= trator.

 

   This d= ocument specifies a new Remote Authentication Dial-In User

   Servic= e (RADIUS) attributes that carry the IP addresses that allow

   CPE de= vices to reach one or multiple MPTCP Concentrators.

Thank you.

 

Cheers,

Med

--_000_8fa2493274644afdbf305f432060f250OPEXCLILM34corporateadr_-- From nobody Wed Mar 9 06:02:50 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722212D6F4; Wed, 9 Mar 2016 06:02:49 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160309140249.30390.24870.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 06:02:49 -0800 Archived-At: Cc: radext@ietf.org, stefan.winter@restena.lu, jouni.nospam@gmail.com, draft-ietf-radext-bigger-packets@ietf.org, radext-chairs@ietf.org, stephen.farrell@cs.tcd.ie Subject: [radext] Last Call: (Larger Packets for RADIUS over TCP) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 14:02:49 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Larger Packets for RADIUS over TCP' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Mar 9 16:57:09 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 844E912DCA3; Wed, 9 Mar 2016 16:57:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160310005706.20505.70432.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 16:57:06 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-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: 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 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/ From nobody Wed Mar 9 17:09:36 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA612DDC5; Wed, 9 Mar 2016 17:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrg4fvGuu96D; Wed, 9 Mar 2016 17:09:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D6912D7B6; Wed, 9 Mar 2016 17:09:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKE13054; Thu, 10 Mar 2016 01:09:27 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Mar 2016 01:09:26 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.143]) by SJCEML703-CHM.china.huawei.com ([169.254.5.158]) with mapi id 14.03.0235.001; Wed, 9 Mar 2016 17:09:22 -0800 From: Dean cheng To: "lionel.morand@orange.com" , "radext@ietf.org" Thread-Topic: Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSgGiVdLw Date: Thu, 10 Mar 2016 01:09:22 +0000 Message-ID: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.109] Content-Type: multipart/mixed; boundary="_002_DC7880973D477648AC15A3BA66253F686E8CA97ESJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56E0C948.0033, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.143, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0767abb8f20211f0a24ef86c52708275 Archived-At: Cc: Stefan Winter , Alan DeKok , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 01:09:35 -0000 --_002_DC7880973D477648AC15A3BA66253F686E8CA97ESJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lionel,=20 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 >=20 > Hi, >=20 > Acting as Shepherd of the document draft-ietf-radext-ip-port-radius-ext-0= 6, > 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. >=20 > 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 i= s > therefore no unique type. See comment on IANA section. >=20 > Please see hereafter further details on the changes . >=20 > Regards, >=20 > Lionel >=20 > *************** >=20 > Abstract >=20 > 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. >=20 > Usually, we need to limit the use of acronym in the abstract when not > required. > A proposal would be: >=20 > s/CGN (Carrier Grade NAT)/Carrier-Grade NAT > s/NAT64/IPv6/IPv4 gateway >=20 > ****** >=20 > 1. Introduction >=20 > "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." >=20 >=20 > In a broadband network --> In broadband access network Border Network > Gateway (BNG) --> Broadband Network Gateway (BNG) >=20 > comment: In Broadband access network, the BNG acts as a NAS ( not > collocated with) >=20 > Porposed modificiation: >=20 > 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. >=20 > Comment: check the consistency all acrossthe document regarding NAS/BNG >=20 > ******* >=20 > "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." >=20 > Proposed modification: >=20 > 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 t= he > NAS/BNG. >=20 > ******* >=20 > "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." >=20 > Comment: the NAS/BNG is ont that exhanges withthe server, not the CGN. >=20 > Proposed modification: >=20 >=20 > "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." >=20 > ******* >=20 > "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." >=20 > Comment: the CGN does not communicate with the RADIUS server. And not sur= e > that it is needed to speak about that here. >=20 > proposed modification: >=20 > The CGN may perform NAT44 [RFC3022], NAT64 [RFC6146], or Dual-Stack > Lite AFTR [RFC6333] function. >=20 > comment: difficult to see the link between this text and what is before a= nd > after. Is it required here? >=20 > ******* >=20 > "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." >=20 > Proposed simplification: >=20 > When IP packets traverse the CGN, it performs TCP/UDP source port > mapping or ICMP identifier mapping as required. >=20 > ******** >=20 > "This is required for identification purposes (see TR-146 [TR-146] for > example)." >=20 > "for more details" would be more appropriate. >=20 >=20 > ******** >=20 >=20 > "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." >=20 > s/RADIUS Acces-Accept/RADIUS Access-Accept >=20 > s/IP subscriber/user ??? >=20 > ******** >=20 > "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." >=20 > s/subscriber/user ??? >=20 > ******* >=20 > "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." >=20 >=20 > the last sentence is not clear. >=20 > Proposed change (to check/clarify): >=20 > 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 i= ts > respective IPv4 address. >=20 > ******** >=20 > "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)." >=20 > 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. >=20 > Here is a proposal: >=20 > 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). >=20 > ******* >=20 > "This document was constructed using the [RFC2629]." > can be removed. >=20 > ****** >=20 > 2. Terminology >=20 > This document makes use if the following terms: >=20 > s/makes use if/makes use of >=20 > ****** >=20 > o IP Port Range: specifies a set of contiguous IP ports, indicated > by the smallest numerical number and the largest numerical number, > inclusively. >=20 > s/smallest/lowest > s/largest/highest >=20 > ****** >=20 >=20 > 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]. >=20 > When defining "Internal IP Address", is the last sentence really required= ? > Otherwise, you would have to describe the otehr possible cases, that it i= s > not needed at this stage. >=20 >=20 > ****** >=20 > 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. >=20 > same comment >=20 > ****** >=20 > o External realm: refers to the networking segment where IPv4 public > addresses are used in respective of the device supporting port > ranges. >=20 > s/where IPv4 public addresses/where external IP addresses >=20 > o Internal realm: refers to the networking segment that is behind a > device supporting port ranges and where IPv4 private addresses are > used. >=20 > S/where IPv4 private addresses/where internal IP addresses >=20 > ******* >=20 > 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]. >=20 > proposed change (for clarity): >=20 > 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]. >=20 >=20 > ***** >=20 > 3. Extensions of RADIUS Attributes and TLVs >=20 > [...] >=20 > I propose to add here the following text. >=20 > In all the figures describing the RADIUS attribute and TLV formats in > the > following sections, the fields are transmitted from left to right. >=20 > 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. >=20 > ***** >=20 > 3.1.1. IP-Port-Limit Attribute >=20 > 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). >=20 > proposed change: >=20 > 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). >=20 >=20 > ***** >=20 > 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. >=20 > s/the port limit is applied to/the port limit applies to >=20 > ***** >=20 > 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. >=20 > Proposed change: >=20 > 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. >=20 > ***** >=20 > The IP-Port-Limit Attribute MUST NOT appear in any other RADIUS > packets. >=20 > s/any other RADIUS packets/any other RADIUS packet >=20 > ******* >=20 > Type: >=20 > TBA1. >=20 > proposed change: >=20 > Type: >=20 > 241 (To be confirmed by IANA). >=20 > ******* >=20 > 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)}]. >=20 > What is defined is a new type space. therefore the text should be only: >=20 > IP-Port-Limit attribute is associated with the following identifier: > 241.TBA2. >=20 > ****** >=20 > 3.1.2. IP-Port-Range Attribute >=20 > 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). >=20 > Proposed change: >=20 > 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). >=20 > ****** >=20 > 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. >=20 > s/is intended to send/is intended to be sent >=20 > ******* >=20 > The IP-Port-Range Attribute MUST NOT appear in any other RADIUS > packets. >=20 > s/any other RADIUS packets/any other RADIUS packet >=20 > ******* >=20 > Type: >=20 > TBA1. >=20 > Proposed change: >=20 > Type: >=20 > 241 (To be confirmed by IANA). >=20 >=20 > ******* >=20 > 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)}]. >=20 > same comment as baove regarding type space: >=20 > The IP-Port-Range attribute is associated with the following > identifier: 241.TBA3. >=20 > ****** >=20 > 3.1.3. IP-Port-Forwarding-Map Attribute >=20 > 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). >=20 > "IP-Port-Ext-IP-Addr TLV" should be "IP-Port-Ext-IPv4-Addr TLV" if I'm > correct >=20 > Proposed change: >=20 > 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). >=20 > ******* >=20 > The attribute MUST NOT appear in any other RADIUS packet. >=20 >=20 > s/The attribute MUST NOT/The IP-Port-Forwarding-Map Attribute >=20 > ******* >=20 > Type: >=20 > TBA1. >=20 > Proposed change: >=20 > Type: >=20 > 241 (To be confirmed by IANA). >=20 > ******** >=20 > 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)}]. >=20 > same comment as baove regarding type space: >=20 > The IP-Port-Forwarding-Map attribute is associated with the following > identifier: 241.TBA4. >=20 > ******* >=20 > 3.2.1. IP-Port-Type TLV >=20 > 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: >=20 > s/Its Type field/Its "Type" field > s/its Value field/its "Value" field > s/refers to IPFIX Element transportType (TBAx1)/refers to IPFIX Informati= on > Element "transportType" (TBAx1) s/contains IPFIX Element > transportType/contains the values defined for the IPFIX Information Eleme= nt > "transportType" >=20 > comment: the same applies for the TLV defined in this document. (section > 3.2.1 to 3.2.11) >=20 > s/indicates the type of IP transport type/indicates the type of IP > transport >=20 > ****** >=20 > Just before figure 4, Add: >=20 > 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). >=20 >=20 > ****** > Type: >=20 > TBA5:This uniquely refers to IPFIX Element ID TBA0. >=20 > proposed change: >=20 > Type: >=20 > The value depends on the encapsulating attribute (see IANA section)= . > This Must uniquely refer to IPFIX ElementID TBA0. >=20 > comment: same comment for all the TLV >=20 > ****** >=20 > transportType: >=20 > 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. >=20 > must be --> MUST be ? >=20 > ***** >=20 > 3.2.2. IP-Port-Limit TLV >=20 > 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. >=20 > Should the last sentence be reversed? >=20 > "...which indicates the maximum number of ports for a given IPv4 address > assigned to a subscriber for a specified IP-Port-Type." >=20 >=20 > ****** >=20 > Just before figure 5, Add: >=20 > IP-Port-Limit TLV is included as part of the IP-Port- > Limit Attribute (refer to Section 3.1.1). >=20 >=20 > ****** >=20 >=20 > natTransportLimit: >=20 > 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. >=20 > must be --> MUST be? >=20 > ***** >=20 > 3.2.3. IP-Port-Ext-IPv4-Addr TLV >=20 > [...] >=20 > 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). >=20 > Can --> MAY as it refers to a normative optionality. >=20 > ***** >=20 > 3.2.4. IP-Port-Int-IPv4-Addr TLV >=20 > [...] >=20 > IP-Port-Int-IPv4-Addr TLV can be included as part of the IP-Port- > Forwarding-Map Attribute (refer to Section 3.1.3). >=20 > Can --> MAY as it refers to a normative optionality. >=20 > ***** >=20 > 3.2.5. IP-Port-Int-IPv6-Addr TLV >=20 > [...]. >=20 > IP-Port-Int-IPv6-Addr TLV can be included as part of the IP-Port- > Forwarding-Map Attribute (refer to Section 3.1.3). >=20 > Can --> MAY as it refers to a normative optionality. >=20 > ***** >=20 > 3.2.11. IP-Port-Local-Id TLV >=20 > [...] >=20 > 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). >=20 > Can --> MAY as it refers to a normative optionality. >=20 > ***** >=20 > 4.1. Managing CGN Port Behavior using RADIUS >=20 > In a broadband network, customer information is usually stored on a > RADIUS server, and the BNG hosts the NAS. >=20 > s/BNG hosts the NAS/BNG acts as a NAS >=20 > ***** >=20 > A CGN function in a broadband network would most likely reside on a > BNG. >=20 > s/likely reside/likely collocated >=20 > ***** >=20 > 4.1.1. Configure IP Port Limit for a User >=20 > 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. >=20 > s/resource, i.e., the IPv4 address/resource, i.e., the IPv4 address, >=20 > 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. >=20 > ***** >=20 > 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. >=20 > s/The value of these IP port limit/he value of this IP port limit >=20 > ***** >=20 > 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. >=20 > proposed change: >=20 > 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. >=20 > ****** >=20 > Figure 17/18/19: use NAT44 or only NAT in the fugures for consistency >=20 >=20 > ***** >=20 > 5. Table of Attributes >=20 > This document proposes three new RADIUS attributes and their formats > are as follows: >=20 > o IP-Port-Limit: TBA1.TBA2.[TBA6, TBA5, {TBA7}] >=20 > o IP-Port-Range: TBA1.TBA3.[TBA12, TBA5, {TBA13, TBA14}, {TBA7}, > {TBA15}]. >=20 > o IP-Port-Forwarding-Map: TBA1.TBA4.[TBA10, TBA11, TBA5, {TBA8 | > TBA9}, {TBA7}] >=20 > proposed change(see IANA section): >=20 > 5. Table of Attributes >=20 > This document proposes three new RADIUS attributes and their formats > are as follows: >=20 > o IP-Port-Limit: 241.TBA2 >=20 > o IP-Port-Range: 241.TBA3 >=20 > o IP-Port-Forwarding-Map: 241.TBA4 >=20 > Note to IANA: it is assumed that Extended-Type-1 "241" will be used for > theses attributes >=20 > ******** >=20 >=20 > 6. Security Considerations >=20 > This document does not introduce any security issue than what has > been identified in [RFC2865]. >=20 > proposed change: >=20 > This document does not introduce any security issue other than the > ones already identified in RADIUS [RFC2865]. >=20 > ******* >=20 > 7.1. IANA Considerations on New IPFIX Elements >=20 > s/IPFIX Elements/IPFIX Information Elements >=20 > ******** >=20 > The following are code point assignments for new IPFIX Elements as > requested by this document: >=20 > s/for new IPFIX Elements/for new IPFIX Information Elements >=20 > **** >=20 > 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). >=20 > s/this IPFIX Element/this IPFIX Information Element >=20 > ***** >=20 > 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. >=20 > s/this IPFIX Element/this IPFIX Information Element >=20 > ***** >=20 > 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. >=20 > s/this IPFIX Element/this IPFIX Information Element >=20 > ****** >=20 > Proposed change for IANA (see below for nested TLVs): >=20 > 7.2. IANA Considerations on New RADIUS Attributes >=20 > 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. >=20 > 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]: >=20 >=20 > 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 >=20 >=20 > ****** >=20 > Comment: The TLVs are defined within a given extended-Type attribute spac= e. >=20 > proposed modification: >=20 > 7.3. IANA Considerations on New RADIUS Nested Attributes >=20 > This specification requests allocation of the following TLVs > within the attribute IP-Port-Limit 241.TBD2: >=20 > 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 >=20 > This specification requests allocation of the following TLVs > within the attribute IP-Port-Range 241.TBD3: >=20 > 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 >=20 > This specification requests allocation of the following TLVs > within the attribute IP-Port-Forwarding-Map 241.TBD4: >=20 > 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 >=20 > _________________________________________________________________________= __ > ______________________________________________ >=20 > 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'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > 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 bee= n > modified, changed or falsified. > Thank you. --_002_DC7880973D477648AC15A3BA66253F686E8CA97ESJCEML701CHMchi_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Thu, 10 Mar 2016 01:09:20 GMT"; modification-date="Thu, 10 Mar 2016 01:09:20 GMT" Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by SJCEML703-CHM.china.huawei.com (10.218.25.36) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Mar 2016 16:57:31 -0800 Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by dfweml705-chm.china.huawei.com (10.193.5.142) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Mar 2016 16:57:28 -0800 Received: from szxwg02-in.huawei.com (172.24.1.114) by SZXEML425-HUB.china.huawei.com (10.82.67.180) with Microsoft SMTP Server id 14.3.235.1; Thu, 10 Mar 2016 08:57:22 +0800 Received: from mail.ietf.org (unknown [4.31.198.44]) by Websense Email with ESMTPS id 7C2B3C7543A06; Thu, 10 Mar 2016 08:57:17 +0800 (CST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D4812DCA6; Wed, 9 Mar 2016 16:57:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 844E912DCA3; Wed, 9 Mar 2016 16:57:06 -0800 (PST) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" CC: "radext@ietf.org" Subject: I-D Action: draft-ietf-radext-ip-port-radius-ext-07.txt Thread-Topic: I-D Action: draft-ietf-radext-ip-port-radius-ext-07.txt Thread-Index: AQHRemfTlwhU0XkSvkKoXU3FGmKimA== Sender: I-D-Announce Date: Thu, 10 Mar 2016 00:57:06 +0000 Message-ID: <20160310005706.20505.70432.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: szxeml425-hub.china.huawei.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <00C7A74D9026C245A6CC18C22DBBCB0F@huawei.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions of the IETF. Title : RADIUS Extensions for IP Port Configuration and R= eporting 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: 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 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=3Ddraft-ietf-radext-ip-port-radius-ext-07 Please note that it may take a couple of minutes from the time of submissio= n 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 I-D-Announce@ietf.org 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 --_002_DC7880973D477648AC15A3BA66253F686E8CA97ESJCEML701CHMchi_-- From nobody Thu Mar 10 07:22:59 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DEB12D792; Thu, 10 Mar 2016 07:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4RmSKSEUmGG; Thu, 10 Mar 2016 07:22:54 -0800 (PST) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F96F12D78F; Thu, 10 Mar 2016 07:22:47 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 7E7D422B94; Thu, 10 Mar 2016 16:22:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 3C01B1C0064; Thu, 10 Mar 2016 16:22:45 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0279.002; Thu, 10 Mar 2016 16:22:44 +0100 From: To: Dean cheng , "radext@ietf.org" Thread-Topic: Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSgGiVdLwAByVdPA= Date: Thu, 10 Mar 2016 15:22:44 +0000 Message-ID: <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Stefan Winter , Alan DeKok , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 15:22:58 -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 p= rotocol, it could be better to avoid to use the same name "IP-Port-Limit" f= or the attribute and the sub-attribute. What about "IP-Port-Limit-Info" (or something else) for the attribute name?= =20 - Comment: the TDB values start with TBD2 (as TBD1 was replaced by 241). Yo= u can keep the numbering as it is but don't forget this point when IANA wil= l 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=A0: Dean cheng [mailto:dean.cheng@huawei.com] > Envoy=E9=A0: jeudi 10 mars 2016 02:09 > =C0=A0: MORAND Lionel IMT/OLN; radext@ietf.org > Cc=A0: Alan DeKok; Stefan Winter; draft-ietf-radext-ip-port-radius- > ext.authors@ietf.org > Objet=A0: RE: Shepherd review of draft-ietf-radext-ip-port-radius-06 >=20 > Hi Lionel, >=20 > 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. >=20 > Please review and let us know if there is any other comments, and we look > forward to your submission to IESG. >=20 > Regards > Draft authors >=20 > > -----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] f= or > > 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 po= rt > > (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 requir= ed? > > 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 sectio= n). > > 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. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Thu Mar 10 07:51:23 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FEC12D8EC; Thu, 10 Mar 2016 07:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGT2Uk2j-Sy4; Thu, 10 Mar 2016 07:51:15 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9F68C12D8E9; Thu, 10 Mar 2016 07:51:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D151ECD5; Thu, 10 Mar 2016 15:51:14 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bZgfFZ_mHsV; Thu, 10 Mar 2016 15:51:14 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 213F114A; Thu, 10 Mar 2016 15:51:14 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Thu, 10 Mar 2016 10:51:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7CAF2C8D-A986-4DA5-9C75-7A9817B763D4@freeradius.org> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Dean cheng , "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , Winter Stefan Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 15:51:21 -0000 On Mar 10, 2016, at 10:22 AM, = wrote: > - 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?=20 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 nobody Thu Mar 10 08:15:47 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9907F12D847; Thu, 10 Mar 2016 08:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xbpdo6G0vKbZ; Thu, 10 Mar 2016 08:15:45 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3E79C12D967; Thu, 10 Mar 2016 08:15:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 9AEDDC08; Thu, 10 Mar 2016 16:15:44 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSVUsSp4LL3g; Thu, 10 Mar 2016 16:15:44 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id D85E531F; Thu, 10 Mar 2016 16:15:43 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Thu, 10 Mar 2016 11:15:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Dean cheng , "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , Winter Stefan Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 16:15:46 -0000 On Mar 10, 2016, at 10:22 AM, = wrote: > - Section 3.2.2 >=20 > Type: >=20 > TBD2.2. It MUST uniquely refer to the IPFIX Information Element > identifier TBAx2. 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 nobody Fri Mar 11 10:25:11 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F1D12D9D9; Fri, 11 Mar 2016 10:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7XxdYI1G66y; Fri, 11 Mar 2016 10:25:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2740712D7E8; Fri, 11 Mar 2016 10:24:22 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6CD0022C727; Fri, 11 Mar 2016 19:24:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 482EC35C048; Fri, 11 Mar 2016 19:24:20 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Fri, 11 Mar 2016 19:24:20 +0100 From: To: Alan DeKok Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSgGiVdLwAByVdPAAAU2XAAA3k7Rg Date: Fri, 11 Mar 2016 18:24:19 +0000 Message-ID: <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.11.162417 Archived-At: Cc: Dean cheng , "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , Winter Stefan Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 18:25:10 -0000 Hi Alan, thank you for your review. Please see below. regards Lionel > -----Message d'origine----- > De=A0: Alan DeKok [mailto:aland@freeradius.org] > Envoy=E9=A0: jeudi 10 mars 2016 17:16 > =C0=A0: MORAND Lionel IMT/OLN > Cc=A0: Dean cheng; radext@ietf.org; Winter Stefan; draft-ietf-radext-ip-p= ort- > radius-ext.authors@ietf.org > Objet=A0: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radiu= s-06 >=20 > On Mar 10, 2016, at 10:22 AM, > wrote: > > - Section 3.2.2 > > > > Type: > > > > TBD2.2. It MUST uniquely refer to the IPFIX Information Element > > identifier TBAx2. >=20 > I've taken a look at the IANA assignments, and I think some clarificati= on is > necessary. >=20 > The ASCII art is problematic, because it shows only the TLV encoding, a= nd > 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. >=20 > > TB2.2. --> 241.TB2.2 >=20 > That's again confusing. The "241.TBD2.2" name implies that the attribu= te > has type / extended-type / tlv-type. Yet the ASCII art only shows one "t= ype" > field. >=20 > I suggest using "TLV-Type" instead of "Type" in the ASCII art and asso= ciated > text, to make it clear that only the TLV portion is being defined here. [LM] Right! >=20 > Ideally, also reference the data types draft ((informational), and say = you're > using the same naming scheme as there. [LM] OK. Can be done in the introduction of section 3 (true for attribute a= nd TLV) >=20 > I suggest removing the colons after the field names. It's unusual, and= hasn't > been done before in RADIUS RFCs. e.g. >=20 > Type: >=20 > explanatory text >=20 > to: >=20 > TLV-Type >=20 > explanatory text >=20 > There are a *lot* of unnecessary colons in field names. [LM] ok >=20 >=20 > 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-attribut= es. > Each of the sub-attributes can have their numbers assigned explicitly, st= arting > at 1. The definition of each sub-attribute should say that this sub-attr= ibute is > contained within the parent attribute. >=20 > I'm not clear on the text for many sub-attributes. e.g. Section 3.2.1 = IP-Port- > Type TLV >=20 > Type: >=20 > The value depends on the encapsulating attribute (see IANA > Section). This MUST uniquely refer to the IPFIX Information > Element identifier TBAx1. >=20 >=20 > What does that mean? It's confusing. [LM] TYPE is actually TYPE.EXTENDED-TYPE.TLV-TYPE here. And as the same TL= V can be reused in different attributes, the identifier depends on the TYPE= .EXTENDED-TYPE.=20=20 >=20 > 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-attri= butes, > 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 n= amespace starting by 1 (TYPE.EXTENDED-TYPE.1). Therefore, the number is onl= y 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 use= d in the three attributes in the future, it would have automatically the va= lue 4 for the first one, 6 for the second and 8 for the third one. >=20 > It also avoids the confusing text noted above. Instead, we could just = have > IP-Port-Type TLV say: >=20 > TLV-Type >=20 > 1 >=20 > Which is clear and has no potential for confusion. >=20 [LM] see above. > This also makes Section 7.3 simpler. You can just define the sub-attri= butes, > and tell IANA to allocate those numbers in all of the three parents. The= re > should be a note that all three parents MUST have identical children. I = don't > think there's a reason to do anything else. >=20 > 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. >=20 [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 d= rive to misimplementation. > Alan DeKok. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Fri Mar 11 11:10:06 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8423312DAB0; Fri, 11 Mar 2016 11:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcN0039A20h0; Fri, 11 Mar 2016 11:10:02 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AB3DD12DAAF; Fri, 11 Mar 2016 11:10:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D11CD6BA; Fri, 11 Mar 2016 19:10:00 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMjxuRpEzH9B; Fri, 11 Mar 2016 19:10:00 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id B8B8031D; Fri, 11 Mar 2016 19:09:59 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5AF50CDE-F004-4138-8DEE-8A4A046B793E"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Alan DeKok In-Reply-To: <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Fri, 11 Mar 2016 14:10:01 -0500 Message-Id: <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Dean cheng , "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , Winter Stefan Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 19:10:04 -0000 --Apple-Mail=_5AF50CDE-F004-4138-8DEE-8A4A046B793E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 11, 2016, at 1:24 PM, = wrote: >=20 > [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. >=20 > [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. >> 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. >>=20 > [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. --Apple-Mail=_5AF50CDE-F004-4138-8DEE-8A4A046B793E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW4xgKAAoJEH0Oec13Yh7NcfoH/0LCeFT0rWaPlrXC0C8vSkYo 6c4q9IJBVbTaoeDxAMRd2gR4Ydqz+uYEAoDj81yS7cJ99Wy8/rypA/Jf0xho9jqA ULAgrbsiAnkjATwGtAiEd8nf5+jZ6xvomN2xGdPAOrkVB9zPLPz03pAV6TvU7VeH p6clKMzglxdWF/EuwAJ5hfIk5mEzYpyw31jhvRSpu94zBddWX0VGw61q5TisMMaX hhanmsfMX5es3XrFm7eimIPMiI7TBonD8p4UUugBLAabx8Appgr/gdCUVQvUakxp hk9nH/MhTHYPEnkaR+QtmUqONLG4iVHxn0bCWnJ6y0+b+nwOT6WAUR3V807pj1M= =NfGm -----END PGP SIGNATURE----- --Apple-Mail=_5AF50CDE-F004-4138-8DEE-8A4A046B793E-- From nobody Fri Mar 11 15:05:35 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2395912DD7C; Fri, 11 Mar 2016 15:05:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230522.15028.74206.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:22 -0800 Archived-At: Cc: radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com Subject: [radext] radext - Requested session has been scheduled for IETF 95 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:22 -0000 Dear Stefan Winter, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. radext Session 1 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Buen Ayre A size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: RADIUS EXTensions Area Name: Operations and Management Area Session Requester: Stefan Winter Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: mif dime 6man v6ops dmm abfab oauth saag Second Priority: spring sfc rtcweb 6lo netext ace httpauth mile ipsecme Special Requests: --------------------------------------------------------- From nobody Mon Mar 14 18:27:03 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B84CD12D57C; Mon, 14 Mar 2016 18:27:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160315012702.31467.28371.idtracker@ietfa.amsl.com> Date: Mon, 14 Mar 2016 18:27:02 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 01:27:02 -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-08.txt Pages : 36 Date : 2016-03-14 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 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-08 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/ From nobody Mon Mar 14 18:42:52 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD9812D84D; Mon, 14 Mar 2016 18:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40V38rGUVwrW; Mon, 14 Mar 2016 18:42:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E760312D559; Mon, 14 Mar 2016 18:42:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKP00727; Tue, 15 Mar 2016 01:42:44 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Mar 2016 01:42:43 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.126]) by SJCEML703-CHM.china.huawei.com ([169.254.5.228]) with mapi id 14.03.0235.001; Mon, 14 Mar 2016 18:42:36 -0700 From: Dean cheng To: Alan DeKok , "lionel.morand@orange.com" Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AQHRe8mlG33G0jkBW0SZ6xQgiSGpU59ZvDXw Date: Tue, 15 Mar 2016 01:42:33 +0000 Message-ID: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> In-Reply-To: <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56E76894.00E9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.126, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8f4c69e958cd4a4c6de32f0a8d69c028 Archived-At: Cc: "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , Winter Stefan Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 01:42:51 -0000 Hi Alan & Lionel, Thanks for the comments, and we believe we've incorporated all please see the 08.txt just=20 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. > -----Original Message----- > From: Alan DeKok [mailto:aland@freeradius.org] > Sent: Friday, March 11, 2016 11:10 AM > To: lionel.morand@orange.com > Cc: Dean cheng; radext@ietf.org; Winter Stefan; draft-ietf-radext-ip-port= - > radius-ext.authors@ietf.org > Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius= - > 06 >=20 > On Mar 11, 2016, at 1:24 PM, > wrote: > > > > [LM] TYPE is actually TYPE.EXTENDED-TYPE.TLV-TYPE here. And as the sam= e > TLV can be reused in different attributes, the identifier depends on the > TYPE.EXTENDED-TYPE. >=20 > My concern is the idea of the "same" TLV. If it's the same TLV, I woul= d > *strongly* prefer using the same TLV-Type value. >=20 > >> 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 o= wn > namespace starting by 1 (TYPE.EXTENDED-TYPE.1). Therefore, the number is > only significant for a given (parent) attribute. >=20 > All true. >=20 > > 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 futu= re, > it would have automatically the value 4 for the first one, 6 for the seco= nd > and 8 for the third one. >=20 > 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. >=20 > 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. >=20 > >> 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. >=20 > I agree. We have two choices here: >=20 > 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. >=20 > 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 TL= V. > 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 defi= ne > a standard of any kind. >=20 > 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. >=20 > The half & half solution is worse (for me) than either (1) or (2) above= . >=20 > Alan DeKok. From nobody Wed Mar 16 01:48:13 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CACB12D869 for ; Wed, 16 Mar 2016 01:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbzKmihchhVo for ; Wed, 16 Mar 2016 01:48:10 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CFA412D80B for ; Wed, 16 Mar 2016 01:48:10 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D85E243AA0 for ; Wed, 16 Mar 2016 09:48:07 +0100 (CET) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56E91DC7.9050600@restena.lu> Date: Wed, 16 Mar 2016 09:48:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1cA1kM1pFbrf0QegTgjrCPvKpwrc0u2fx" Archived-At: Subject: [radext] Remote presentations? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 08:48:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1cA1kM1pFbrf0QegTgjrCPvKpwrc0u2fx Content-Type: multipart/mixed; boundary="r6iExrsFwgIs0SKGb9Vwu7fgemvlSCXhJ" From: Stefan Winter To: "radext@ietf.org" Message-ID: <56E91DC7.9050600@restena.lu> Subject: Remote presentations? --r6iExrsFwgIs0SKGb9Vwu7fgemvlSCXhJ Content-Type: multipart/mixed; boundary="------------090202040701060500070701" This is a multi-part message in MIME format. --------------090202040701060500070701 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, if any of you want to do a remote presentation, please let the chairs know: we need to book this in advance with MeetEcho. The deadline for letting us know is 02 April. Greetings, Stefan & Lionel --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------090202040701060500070701 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090202040701060500070701-- --r6iExrsFwgIs0SKGb9Vwu7fgemvlSCXhJ-- --1cA1kM1pFbrf0QegTgjrCPvKpwrc0u2fx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW6R3HAAoJEMDeajWKOdxmvGMP/1IH6kGg6PYskx1goJQ1MbdB 8kmgxj3KutTG0P8sHPFedDchKavy2HPsnhKd+XLNPmTrhsJ1OnnuOfpTJR57Bi5g fEzFhhEgAXLU6zv5TBmklnp8fvfIhAZbLkzUxzQ/9eGd2vZGMlx1AFz7sZafkWXD 179+Uq265KbjVvh1b/2yj0HxTRDKlPyD5fCbToUPIxMlPddIOVqTVr1VHrNHnAT9 rebIijxkoX3JTt8rL9ydJj3kKDeUKy+PAmJ/ZBLqfopQ82KBsShD2t/6rQkSzLuM 9CuqP8A9j7G8flbNGleKYrE1faZcIcdRAPc8iaLPun8lANvFQNchPWAnIc/S/ZhR PKBus4KxIRmCiTUFvstxMoeuYNDApTqLuVrT8DGsdAdnchqBwuOu19qmTE4xsTim 0PbS1UDUv8S4kZyxxem4uqdp2XaNt7WZVj+stZyCqdl6VzX/SnHBeEXrouDIB9zQ L+U90GDWVEjyIwGFup5jlTtfZTYcMij18/5m5lylts1VhkAMfyV9KTIzY626HX8v TZJKTkH/cC6o3WdWesCd3U/OwRoyrdhAoDsCuyEGS09a1nhfs0owQhR2oMAZEYKV BA9v+jmulrsKcOMETQbsQpXiBEBGXe18I/9PHM7PgXiROiE/MGNeNPgsc97fjwh2 X683TSqwZq+UOHgm5bTC =rl9+ -----END PGP SIGNATURE----- --1cA1kM1pFbrf0QegTgjrCPvKpwrc0u2fx-- From nobody Wed Mar 16 02:22:24 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE23B12D8E7 for ; Wed, 16 Mar 2016 02:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCFL1crivFYI for ; Wed, 16 Mar 2016 02:22:21 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9F312D8F5 for ; Wed, 16 Mar 2016 02:22:20 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 044CC43ADE for ; Wed, 16 Mar 2016 10:22:19 +0100 (CET) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56E925CA.7040802@restena.lu> Date: Wed, 16 Mar 2016 10:22:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l9EEJ05D1otI4PNPS5KJnflP9laNBCQtR" Archived-At: Subject: [radext] preliminary agenda for radext@IETF95 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 09:22:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l9EEJ05D1otI4PNPS5KJnflP9laNBCQtR Content-Type: multipart/mixed; boundary="tmMrB8oQo2BJsgM7koJHkIidrqmfuSXUk" From: Stefan Winter To: "radext@ietf.org" Message-ID: <56E925CA.7040802@restena.lu> Subject: preliminary agenda for radext@IETF95 --tmMrB8oQo2BJsgM7koJHkIidrqmfuSXUk Content-Type: multipart/mixed; boundary="------------040908050108040303080508" This is a multi-part message in MIME format. --------------040908050108040303080508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I've put up a preliminary agenda: https://www.ietf.org/proceedings/95/agenda/agenda-95-radext RADEXT WG IETF 95 Agenda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Chairs: Stefan Winter Lionel Morand Jabber room: radext at jabber.ietf.org (Please join) Time and Day: Friday 08 April 2016, 1220-1320 Place: Buen Ayre A Preliminaries (10 min) ---------------------- Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Working group draft discussion (20 minutes) ------------------------------------------- draft-ietf-radext-ip-port-radius-ext-08 : 5 min draft-ietf-radext-coa-proxy-00 : 10 min draft-ietf-radext-populating-eapidentity-00: 5 min Individual Drafts (10 minutes) ----------------- draft-boucadair-mptcp-radius-01 : 10 min Wrap-up (5 minutes) -------------------- Next Steps: WG Chairs & ADs -- remaining time: 15 minutes -- Reserve List ------------ "fun little proof of concept for WiFi 10 min authentication" - Alan DeKok --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------040908050108040303080508 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040908050108040303080508-- --tmMrB8oQo2BJsgM7koJHkIidrqmfuSXUk-- --l9EEJ05D1otI4PNPS5KJnflP9laNBCQtR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW6SXKAAoJEMDeajWKOdxm1K8P/ipZCghB66XG65jaYFMYajX+ fcZ2pY19R1mok0+6pmNSLllF2g+4YsKvrP0AIkLmqBt2xEeUb5oqRoKQ3zLF7BaZ vp8zOUJLwqS6Utkyxrec8m2mEKQ27BiAPIXvFNlnOfHPChCdbcO4JT//C7ktrSHT rM3VQl7jbB5nTvrhCFQbqSdr1ShTUAH6AnORVcouhqgHuWENJJy8ds35yUa9Oc7P V0zP6wTJvELgC7xg9qyZXpW74yTAAWG1sTYE4/zaoZvxViegeS9fjXTjUFvq80gK zh+DSOfGH/a1RtHSJ9PD+TZffJMG4U6GWdiuoZa4Izhll2D/wEl5ug84Oy/S/neL prqrfiSFezh9Zxx2BYpZ2gRjnTy39eygI0bqXji4ygFDhWS8ZTSoVlZnJH1e3X5n bmJPi/nsy5OfAfNE6tCBDwqkNV9Bac4rQrUJdDHp2JIbgR7g78LsIL8ynrnV9UPd Z62w/YTz+dICBOBx7hB0hZlmZoSuZ5Y3LTQ2AO/XMpuJpa/866Gv/6ywgOmma7sm L9Amv1PbnQGaUWW87SXagsnQydiDFVeEyUH75wkd3hNx10ZlQ5i0F9ihD6YEZvYT ZeBYglrP9GsEVGeCZaH6A/wes/oYnBi+Jq2Q86vNzyM1TlxGYqdd6ayM61zRNYs0 qFqIfTl3yGUQL710o88u =ygfZ -----END PGP SIGNATURE----- --l9EEJ05D1otI4PNPS5KJnflP9laNBCQtR-- From nobody Wed Mar 16 10:19:16 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4412DA00; Wed, 16 Mar 2016 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L194bPeO_Etx; Wed, 16 Mar 2016 10:19:11 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CA84E12D748; Wed, 16 Mar 2016 10:19:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id DF19219F3; Wed, 16 Mar 2016 17:19:09 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAqn1HCYkCCe; Wed, 16 Mar 2016 17:19:09 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id E0F52CD7; Wed, 16 Mar 2016 17:19:08 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4DDF0937-6099-4D07-B97B-9D2AC9C885AD"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Alan DeKok In-Reply-To: Date: Wed, 16 Mar 2016 13:19:15 -0400 Message-Id: <3B82A79F-E148-4033-9AC2-917221D189B5@freeradius.org> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> To: Dean cheng X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:19:13 -0000 --Apple-Mail=_4DDF0937-6099-4D07-B97B-9D2AC9C885AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 14, 2016, at 9:42 PM, Dean cheng wrote: >=20 > 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'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. :) --Apple-Mail=_4DDF0937-6099-4D07-B97B-9D2AC9C885AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW6ZWTAAoJEH0Oec13Yh7NiPQH+wRlbVgs7L7Gqt1EVB3sA+OG dUzNmk8U6t+31f2t36Y5+nrgEvkiIv83ovX7z+RmLfibeXKYTg3cgId0/n9I+Qta tDuu5RS+6et2x6sTCf/x+i3r+hlnF6QwW/Y4nMfoaUNBWO2UZ4n/C9ivbisAJ2YC cago62FFY8rYzcIUdbUl1BFIB0uUWobr7Ajn9m7bT9KX4n0Oeo/gjvxr6wN1Ja9I TjM4wWVG0rio/rZeJfmw9U05lmZhlLUmaNOaalfyxzsJnj0nc0NOlhgBQ63NjHQl HvgIz9M49hgwPaXJw3gFYkjlnftryd8JUqOWPdx1aVBV/NYCNmZ/ivYETBOzb9M= =tsyH -----END PGP SIGNATURE----- --Apple-Mail=_4DDF0937-6099-4D07-B97B-9D2AC9C885AD-- From nobody Wed Mar 16 11:07:18 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAF412D748; Wed, 16 Mar 2016 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KYzNkrWad_W; Wed, 16 Mar 2016 11:07:14 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F5812D663; Wed, 16 Mar 2016 11:07:13 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id E9307C07A6; Wed, 16 Mar 2016 19:07:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id AAA051A005D; Wed, 16 Mar 2016 19:07:11 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0279.002; Wed, 16 Mar 2016 19:07:11 +0100 From: To: Dean cheng , Alan DeKok Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSgGiVdLwAByVdPAAAU2XAAA3k7RgAADM0YAApJVVgABSMX/Q Date: Wed, 16 Mar 2016 18:07:11 +0000 Message-ID: <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:07:17 -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.=20 About the naming issue, I would suggest to follow the example of the Extend= ed-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. Ext= ended-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 in= side multiple attributes, e.g. IP-Port-Type-1 in the first attribute, IP-Po= rt-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 attribut= e (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=20 3.2.2.3 IP-Port-Local-Id-1. . . . . . . . . . 10=20 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 w= ithin 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 w= ithin 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 w= ithin 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 "examp= le" 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=09 241.26 Extended-Vendor-Specific-1 [RFC6929] 241.{27-240} Unassigned=09 241.{241-255} Reserved [RFC6929] I don't see how using a unique value for sub-attributes would fit in this r= egistry. I hope that this clarifies my point. Regards, Lionel > -----Message d'origine----- > De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Dean cheng > Envoy=E9=A0: mardi 15 mars 2016 02:43 > =C0=A0: Alan DeKok; MORAND Lionel IMT/OLN > Cc=A0: radext@ietf.org; draft-ietf-radext-ip-port-radius-ext.authors@ietf= .org; > Winter Stefan > Objet=A0: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radiu= s-06 >=20 > Hi Alan & Lionel, >=20 > Thanks for the comments, and we believe we've incorporated all please see > the 08.txt just posted. >=20 > 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 e= ach TLV- > section, we also indicated the TLV's identifier. >=20 > E.g. (Section 3.2), the IP-Port-Limit TLV is identified as 241.TBD1.2. >=20 > 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) attribu= te. >=20 > Hope this leads to a compromise. >=20 > Regards > Draft authors. >=20 > > -----Original Message----- > > From: Alan DeKok [mailto:aland@freeradius.org] > > Sent: Friday, March 11, 2016 11:10 AM > > To: lionel.morand@orange.com > > Cc: Dean cheng; radext@ietf.org; Winter Stefan; > > draft-ietf-radext-ip-port- radius-ext.authors@ietf.org > > Subject: Re: [radext] Shepherd review of > > draft-ietf-radext-ip-port-radius- > > 06 > > > > On Mar 11, 2016, at 1:24 PM, > > wrote: > > > > > > [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 desi= gn. > > > > > > [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. > > > > >> 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. > > > > I agree. We have two choices here: > > > > 1) assign each TLV different TLV-Types, depending on the parent attribu= te. > > 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 gen= eric > 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) abo= ve. > > > > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Wed Mar 16 12:15:26 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E378912D5CB; Wed, 16 Mar 2016 12:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr6MdAeE2l0Q; Wed, 16 Mar 2016 12:15:22 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7E96212D64B; Wed, 16 Mar 2016 12:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D1803D9F; Wed, 16 Mar 2016 19:15:21 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByNZ4cehm5R6; Wed, 16 Mar 2016 19:15:21 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 0443BA6B; Wed, 16 Mar 2016 19:15:20 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A3A55715-1113-4A94-BF27-6F54EB1C8C29"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Alan DeKok In-Reply-To: <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Wed, 16 Mar 2016 15:15:27 -0400 Message-Id: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Dean cheng , "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:15:25 -0000 --Apple-Mail=_A3A55715-1113-4A94-BF27-6F54EB1C8C29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 16, 2016, at 2:07 PM, = wrote: >=20 > 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 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. I understand... it just seems awkward to me. Alan DeKok. --Apple-Mail=_A3A55715-1113-4A94-BF27-6F54EB1C8C29 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW6bDPAAoJEH0Oec13Yh7NElkIAJtJYLJGRcC8jMD54OATTPBC Tpzxr9h4+MFzw5MGB33wdOSnS78q/nyNfSGCI/v5lhKj3CITHvMTUW7JMArlWZIp yfrBfzTLm+CvU7tIc//3Ec8VA7lVPxCfNpc3ueCWA0JLmq+0ItUBuAPpO0AP/tmP MY6ZG5cnWfqMjbVqGYIWRgevnd+QH0O6ZUq8he3isG5w4MC8+4jhydWNmAyNzhNS wwhI5fRyFG473baPoLUYXxoodwygMeIIlZdk0CVH1L8D3OqR8EyEnfvMNtLFcIw2 H8occAzqgQVrVZMvVt/MJm+XDk68GVNK75/hK0hu7Lu8yLtmbS/eMdDFgfL1H9U= =qnQw -----END PGP SIGNATURE----- --Apple-Mail=_A3A55715-1113-4A94-BF27-6F54EB1C8C29-- From nobody Wed Mar 16 12:30:58 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1184D12D720; Wed, 16 Mar 2016 12:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzMox_vhrXtl; Wed, 16 Mar 2016 12:30:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F300F12D58A; Wed, 16 Mar 2016 12:30:53 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2BE193B440E; Wed, 16 Mar 2016 20:30:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.63]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0526227C053; Wed, 16 Mar 2016 20:30:52 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0279.002; Wed, 16 Mar 2016 20:30:51 +0100 From: To: Alan DeKok Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSgGiVdLwAByVdPAAAU2XAAA3k7RgAADM0YAApJVVgABSMX/QAATexIAAAqIqTw== Date: Wed, 16 Mar 2016 19:30:51 +0000 Message-ID: <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01E03D58OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.16.162415 Archived-At: Cc: Dean cheng , "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:30:57 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01E03D58OPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxhbiwNCg0KSSB0aGluayB0aGF0IHlvdSBjYW4gY2hlY2sgdGhlIHNlY3Rpb24gMTAuMy42 Og0KDQoxMC4zLjY8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjkyOSNzZWN0aW9uLTEw LjMuNj4uIEFsbG9jYXRpb24gd2l0aGluIGEgVExWDQogICBTcGVjaWZpY2F0aW9ucyBjYW4gcmVx dWVzdCBhbGxvY2F0aW9uIG9mIEF0dHJpYnV0ZSBUeXBlIHZhbHVlcyB3aXRoaW4NCiAgIGFuIEF0 dHJpYnV0ZSBvZiBkYXRhIHR5cGUgVExWLiAgVGhlIGVuY2Fwc3VsYXRpbmcgVExWIGNhbiBiZQ0K ICAgYWxsb2NhdGVkIGluIHRoZSBzYW1lIHNwZWNpZmljYXRpb24sIG9yIGl0IGNhbiBoYXZlIGJl ZW4gcHJldmlvdXNseQ0KICAgYWxsb2NhdGVkLg0KDQogICBTcGVjaWZpY2F0aW9ucyBuZWVkIHRv IHJlcXVlc3QgYWxsb2NhdGlvbiB3aXRoaW4gYSBzcGVjaWZpYyBBdHRyaWJ1dGUNCiAgIFR5cGUg dmFsdWUgKGUuZy4sICJUWVBFLlRMVi4qIikuICBBbGxvY2F0aW9ucyBhcmUgcGVyZm9ybWVkIGZy b20gdGhlDQogICBzbWFsbGVzdCBVbmFzc2lnbmVkIHZhbHVlLCBwcm9jZWVkaW5nIHRvIHRoZSBs YXJnZXN0IFVuYXNzaWduZWQNCiAgIHZhbHVlLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KRW52 b3nDqSBkZXB1aXMgU3VyZmFjZQ0KDQpEZSA6IEFsYW4gRGVLb2s8bWFpbHRvOmFsYW5kQGZyZWVy YWRpdXMub3JnPg0KRW52b3nDqSA6IOKAjm1lcmNyZWRp4oCOIOKAjjE24oCOIOKAjm1hcnPigI4g 4oCOMjAxNiDigI4yMOKAjjrigI4xNQ0Kw4AgOiBMaW9uZWwgTU9SQU5EPG1haWx0bzpsaW9uZWwu bW9yYW5kQG9yYW5nZS5jb20+DQpDYyA6IERlYW4gY2hlbmc8bWFpbHRvOmRlYW4uY2hlbmdAaHVh d2VpLmNvbT4sIHJhZGV4dEBpZXRmLm9yZzxtYWlsdG86cmFkZXh0QGlldGYub3JnPiwgZHJhZnQt aWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LmF1dGhvcnNAaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC5hdXRob3JzQGlldGYub3JnPiwgV2lu dGVyIFN0ZWZhbjxtYWlsdG86c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1Pg0KDQpPbiBNYXIgMTYs IDIwMTYsIGF0IDI6MDcgUE0sIDxsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+IDxsaW9uZWwubW9y YW5kQG9yYW5nZS5jb20+IHdyb3RlOg0KPg0KPiBJIHRoaW5rIHRoYXQgdGhlcmUgaXMgc3RpbGwg YW4gaXNzdWUgcmVnYXJkaW5nIHRoZSB2YWx1ZSBhbGxvY2F0ZWQgZm9yIHN1Yi1hdHRyaWJ1dGVz LiBBcyBwZXIgUkZDNjkyOSwgdGhleSBoYXZlIHRvIGJlIGFsbG9jYXRlZCBwZXIgYXR0cmlidXRl IGFuZCBub3QgZ2xvYmFsbHkuDQoNCiAgV2hpY2ggc2VjdGlvbiBzYXlzIHRoYXQ/ICBTZWN0aW9u IDIgdGFsa3MgYWJvdXQgVExWIHdpdGggVExWLVR5cGUgIjEiIGlzIG5vdCB0aGUgc2FtZSBhcyBV c2VyLU5hbWUgd2l0aCBUeXBlICIxIi4gIEJ1dCBJIGRvbid0IHNlZSBhbnkgcmVzdHJpY3Rpb24g b24gVExWIHJlLXVzZS4NCg0KICBTbyBsb25nIGFzIHRoZSBzcGVjaWZpY2F0aW9uIGlzIGNsZWFy LCBJIHRoaW5rIGl0J3MgT0suDQoNCj4gQWJvdXQgdGhlIG5hbWluZyBpc3N1ZSwgSSB3b3VsZCBz dWdnZXN0IHRvIGZvbGxvdyB0aGUgZXhhbXBsZSBvZiB0aGUgRXh0ZW5kZWQtVmVuZG9yLVNwZWNp ZmljLCB0aGF0IGNvdWxkIGJlIHNlZW4gYXMgdGhlICJzYW1lIiBhdHRyaWJ1dGUgYnV0IGRlZmlu ZWQgaW4gZGlmZmVyZW50IHR5cGUgY29kZXMsIHdpdGggdGhlIG5hbWUgYmVpbmcgc3VmZml4ZWQg YnkgYSBkaWdpdCAoZS5nLiAgRXh0ZW5kZWQtVmVuZG9yLVNwZWNpZmljLTEgZm9yIDI0LjEyNiwg RXh0ZW5kZWQtVmVuZG9yLVNwZWNpZmljLTIgZm9yIDI0Mi4yNiwgZXRjLikuIEkgd291bGQgcHJv cG9zZSB0byByZXVzZSB0aGUgc2FtZSBsb2dpYyBmb3Igc3ViLWF0dHJpYnV0ZXMgcmV1c2VkIGlu c2lkZSBtdWx0aXBsZSBhdHRyaWJ1dGVzLCBlLmcuIElQLVBvcnQtVHlwZS0xIGluIHRoZSBmaXJz dCBhdHRyaWJ1dGUsIElQLVBvcnQtVHlwZS0yIGluIHRoZSBzZWNvbmQgYXR0cmlidXRlLCBldGMu DQoNCiAgSSB1bmRlcnN0YW5kLi4uIGl0IGp1c3Qgc2VlbXMgYXdrd2FyZCB0byBtZS4NCg0KICBB bGFuIERlS29rLg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_6B7134B31289DC4FAF731D844122B36E01E03D58OPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDkxMSI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PjwhLS1odG1sIHsgZm9udC1mYW1pbHk6ICJDb2xvciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29l IFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVp IFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IH0tLT48L3N0eWxlPjxzdHlsZSBk YXRhLWV4dGVybmFsc3R5bGU9InRydWUiPjwhLS0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaCB7Cm1hcmdpbi10b3A6MGluOwptYXJn aW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2lu LWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwgewptYXJnaW46MGluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29MaXN0UGFyYWdy YXBoQ3hTcEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBh cmFncmFwaEN4U3BGaXJzdCwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xp c3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIApw Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBk aXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0IHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdo dDowaW47Cm1hcmdpbi1ib3R0b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9t Oi4wMDAxcHQ7CmxpbmUtaGVpZ2h0OjExNSU7Cn0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGRpcj0ibHRyIj4NCjxkaXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0 eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jv c29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycs ICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPg0KPGRpdj5IaSBBbGFuLDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB0aGluayB0aGF0IHlvdSBjYW4gY2hlY2sgdGhlIHNlY3Rp b24gMTAuMy42Ojxicj4NCjwvZGl2Pg0KPHNwYW4gY2xhc3M9Img0Ij4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pg0KPGg0PjxhIG5hbWU9InNlY3Rpb24tMTAuMy42IiBjbGFzcz0ic2VsZmxpbmsi IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5Mjkjc2VjdGlvbi0xMC4zLjYi IHRhcmdldD0iX3BhcmVudCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjEwLjMuNjwvZm9udD48L2E+ LiBBbGxvY2F0aW9uIHdpdGhpbiBhIFRMVjwvaDQ+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+Jm5i c3A7Jm5ic3A7IFNwZWNpZmljYXRpb25zIGNhbiByZXF1ZXN0IGFsbG9jYXRpb24gb2YgQXR0cmli dXRlIFR5cGUgdmFsdWVzIHdpdGhpbjxicj4NCiZuYnNwOyZuYnNwOyBhbiBBdHRyaWJ1dGUgb2Yg ZGF0YSB0eXBlIFRMVi4mbmJzcDsgVGhlIGVuY2Fwc3VsYXRpbmcgVExWIGNhbiBiZTxicj4NCiZu YnNwOyZuYnNwOyBhbGxvY2F0ZWQgaW4gdGhlIHNhbWUgc3BlY2lmaWNhdGlvbiwgb3IgaXQgY2Fu IGhhdmUgYmVlbiBwcmV2aW91c2x5PGJyPg0KJm5ic3A7Jm5ic3A7IGFsbG9jYXRlZC48YnI+DQo8 YnI+DQombmJzcDsmbmJzcDsgU3BlY2lmaWNhdGlvbnMgbmVlZCB0byByZXF1ZXN0IGFsbG9jYXRp b24gd2l0aGluIGEgc3BlY2lmaWMgQXR0cmlidXRlPGJyPg0KJm5ic3A7Jm5ic3A7IFR5cGUgdmFs dWUgKGUuZy4sICZxdW90O1RZUEUuVExWLiomcXVvdDspLiZuYnNwOyBBbGxvY2F0aW9ucyBhcmUg cGVyZm9ybWVkIGZyb20gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7IHNtYWxsZXN0IFVuYXNzaWduZWQg dmFsdWUsIHByb2NlZWRpbmcgdG8gdGhlIGxhcmdlc3QgVW5hc3NpZ25lZDxicj4NCiZuYnNwOyZu YnNwOyB2YWx1ZS48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0i dHJ1ZSI+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5MaW9u ZWw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkVudm95w6kgZGVwdWlzIFN1cmZhY2U8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctdG9w OiA1cHg7IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13 aWR0aDogMXB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPg0KPGRpdj48Zm9udCBmYWNlPSIg J0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdN aWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJyIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAxNXB0OyBsZXR0ZXItc3BhY2luZzogMC4wMmVtOyBmb250LWZhbWls eTogJnF1b3Q7Q2FsaWJyaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O01laXJ5 byZxdW90OywgJnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCAmcXVvdDtNaWNyb3NvZnQg SmhlbmdIZWkgVUkmcXVvdDssICZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssICZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTJwdDsiPjxiPkRlJm5ic3A7OjwvYj4mbmJzcDs8YSBo cmVmPSJtYWlsdG86YWxhbmRAZnJlZXJhZGl1cy5vcmciIHRhcmdldD0iX3BhcmVudCI+QWxhbg0K IERlS29rPC9hPjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiZuYnNwO+KAjm1lcmNyZWRp4oCO IOKAjjE24oCOIOKAjm1hcnPigI4g4oCOMjAxNiDigI4yMOKAjjrigI4xNTxicj4NCjxiPsOAIDo8 L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSIgdGFyZ2V0 PSJfcGFyZW50Ij5MaW9uZWwgTU9SQU5EPC9hPjxicj4NCjxiPkNjJm5ic3A7OjwvYj4mbmJzcDs8 YSBocmVmPSJtYWlsdG86ZGVhbi5jaGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9wYXJlbnQiPkRl YW4gY2hlbmc8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOnJhZGV4dEBpZXRmLm9yZyIgdGFyZ2V0PSJf cGFyZW50Ij5yYWRleHRAaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1y YWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LmF1dGhvcnNAaWV0Zi5vcmciIHRhcmdldD0iX3BhcmVu dCI+DQpkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQuYXV0aG9yc0BpZXRmLm9y ZzwvYT4sIDxhIGhyZWY9Im1haWx0bzpzdGVmYW4ud2ludGVyQHJlc3RlbmEubHUiIHRhcmdldD0i X3BhcmVudCI+DQpXaW50ZXIgU3RlZmFuPC9hPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSIiPg0KPGRpdj5PbiBNYXIgMTYsIDIwMTYsIGF0IDI6MDcg UE0sICZsdDtsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20mZ3Q7ICZsdDtsaW9uZWwubW9yYW5kQG9y YW5nZS5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRoaW5rIHRoYXQgdGhl cmUgaXMgc3RpbGwgYW4gaXNzdWUgcmVnYXJkaW5nIHRoZSB2YWx1ZSBhbGxvY2F0ZWQgZm9yIHN1 Yi1hdHRyaWJ1dGVzLiBBcyBwZXIgUkZDNjkyOSwgdGhleSBoYXZlIHRvIGJlIGFsbG9jYXRlZCBw ZXIgYXR0cmlidXRlIGFuZCBub3QgZ2xvYmFsbHkuPGJyPg0KPGJyPg0KJm5ic3A7IFdoaWNoIHNl Y3Rpb24gc2F5cyB0aGF0PyZuYnNwOyBTZWN0aW9uIDIgdGFsa3MgYWJvdXQgVExWIHdpdGggVExW LVR5cGUgJnF1b3Q7MSZxdW90OyBpcyBub3QgdGhlIHNhbWUgYXMgVXNlci1OYW1lIHdpdGggVHlw ZSAmcXVvdDsxJnF1b3Q7LiZuYnNwOyBCdXQgSSBkb24ndCBzZWUgYW55IHJlc3RyaWN0aW9uIG9u IFRMViByZS11c2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgU28gbG9u ZyBhcyB0aGUgc3BlY2lmaWNhdGlvbiBpcyBjbGVhciwgSSB0aGluayBpdCdzIE9LLjxicj4NCjxi cj4NCiZndDsgQWJvdXQgdGhlIG5hbWluZyBpc3N1ZSwgSSB3b3VsZCBzdWdnZXN0IHRvIGZvbGxv dyB0aGUgZXhhbXBsZSBvZiB0aGUgRXh0ZW5kZWQtVmVuZG9yLVNwZWNpZmljLCB0aGF0IGNvdWxk IGJlIHNlZW4gYXMgdGhlICZxdW90O3NhbWUmcXVvdDsgYXR0cmlidXRlIGJ1dCBkZWZpbmVkIGlu IGRpZmZlcmVudCB0eXBlIGNvZGVzLCB3aXRoIHRoZSBuYW1lIGJlaW5nIHN1ZmZpeGVkIGJ5IGEg ZGlnaXQgKGUuZy4mbmJzcDsgRXh0ZW5kZWQtVmVuZG9yLVNwZWNpZmljLTEgZm9yIDI0LjEyNiwN CiBFeHRlbmRlZC1WZW5kb3ItU3BlY2lmaWMtMiBmb3IgMjQyLjI2LCBldGMuKS4gSSB3b3VsZCBw cm9wb3NlIHRvIHJldXNlIHRoZSBzYW1lIGxvZ2ljIGZvciBzdWItYXR0cmlidXRlcyByZXVzZWQg aW5zaWRlIG11bHRpcGxlIGF0dHJpYnV0ZXMsIGUuZy4gSVAtUG9ydC1UeXBlLTEgaW4gdGhlIGZp cnN0IGF0dHJpYnV0ZSwgSVAtUG9ydC1UeXBlLTIgaW4gdGhlIHNlY29uZCBhdHRyaWJ1dGUsIGV0 Yy48YnI+DQo8YnI+DQombmJzcDsgSSB1bmRlcnN0YW5kLi4uIGl0IGp1c3Qgc2VlbXMgYXdrd2Fy ZCB0byBtZS48YnI+DQo8YnI+DQombmJzcDsgQWxhbiBEZUtvay48YnI+DQo8YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8 L2h0bWw+DQo= --_000_6B7134B31289DC4FAF731D844122B36E01E03D58OPEXCLILM43corp_-- From nobody Wed Mar 16 12:35:38 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8FB12D70E; Wed, 16 Mar 2016 12:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC9sl-1HLwJd; Wed, 16 Mar 2016 12:35:35 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB412D741; Wed, 16 Mar 2016 12:35:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 60E67D9F; Wed, 16 Mar 2016 19:35:34 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfRjOGZH_EpD; Wed, 16 Mar 2016 19:35:34 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 7FA4DA6B; Wed, 16 Mar 2016 19:35:33 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_28CBB156-68EB-43E5-9D19-4785879DDFBD"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Alan DeKok In-Reply-To: <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Wed, 16 Mar 2016 15:35:40 -0400 Message-Id: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Dean cheng , "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:35:37 -0000 --Apple-Mail=_28CBB156-68EB-43E5-9D19-4785879DDFBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 16, 2016, at 3:30 PM, = wrote: >=20 > Hi Alan, >=20 > 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. --Apple-Mail=_28CBB156-68EB-43E5-9D19-4785879DDFBD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW6bWMAAoJEH0Oec13Yh7NGk8IAKcJ4BDsZ6P/yP7SHSUTHPXZ +b3ba0+vDttf0+BEzjF/k7LENi0B0Frc4GXqafMEK8f5LBqBP5yzAKN3hQBlkfql Es4DrOLZqr92AiCGU5ioiF2a3lUbww2SfmSnY7YukSEBOBsSqJRDnZx2fLYUvpk/ 9lms/GmN9dOFvCdUigM+v0afD8ETUZ4+VSUDOGFsWJ8YUbk2x9y/+TgGvEsb6vgh KVFZnC1HZDd+wkAcqMHcC7wYaDs2S8gxuK7wKv6DhlsokNJRvv6xEtfL0sOQEj7V tcOCZF5HX0bCw+t7K1TEgwMns4V08bf9UTEWhWxrSx1fXQu1xG2ZsvQB/bNVD9M= =kUfG -----END PGP SIGNATURE----- --Apple-Mail=_28CBB156-68EB-43E5-9D19-4785879DDFBD-- From nobody Wed Mar 16 13:04:38 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA56112D6DC; Wed, 16 Mar 2016 13:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoUXeGweKaJY; Wed, 16 Mar 2016 13:04:35 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4583812D6D5; Wed, 16 Mar 2016 13:04:35 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 1F06E400F1; Wed, 16 Mar 2016 21:04:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id EB9E11A0051; Wed, 16 Mar 2016 21:04:33 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%19]) with mapi id 14.03.0279.002; Wed, 16 Mar 2016 21:04:33 +0100 From: To: Alan DeKok Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSgGiVdLwAByVdPAAAU2XAAA3k7RgAADM0YAApJVVgABSMX/QAATexIAAAqIqT///8JQAgAAY1dg= Date: Wed, 16 Mar 2016 20:04:32 +0000 Message-ID: <301_1458158674_56E9BC52_301_7692_1_6B7134B31289DC4FAF731D844122B36E01E03DE6@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01E03DE6OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: Dean cheng , "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 20:04:37 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01E03DE6OPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgd2hhdCBJIGhhdmUgdHJ5IHRvIGRvLCBwdXR0aW5nIElQLVBvcnQtVHlwZSwgSVAtUG9y dC1FeHQtSVB2NC1BZGRyIGF0IHRoZSBmaXJzdCBwbGFjZXMgYnV0IGl0IGRvZXMgbm90IGZseSB3 aGVuIGNvbnNpZGVyaW5nIElQLVBvcnQtTG9jYWwtSWQgdGhhdCBpcyBkZWZpbmVkIG9ubHkgaW4g dHdvIG9mIHRoZSB0aHJlZSBhdHRpYnV0ZXMuDQoNCklmIHlvdSBjb25zaWRlciB0aGUgUkFESVVT IGF0dHJpYnV0ZSB0eXBlcyByZWdpc3RyeSwgd2hhdCB3b3VsZCBiZSB5b3VyIGNvdW50ZXItcHJv cG9zYWw/DQoNCmxpb25lbA0KDQpFbnZvecOpIGRlcHVpcyBTdXJmYWNlDQoNCkRlIDogQWxhbiBE ZUtvazxtYWlsdG86YWxhbmRAZnJlZXJhZGl1cy5vcmc+DQpFbnZvecOpIDog4oCObWVyY3JlZGni gI4g4oCOMTbigI4g4oCObWFyc+KAjiDigI4yMDE2IOKAjjIw4oCOOuKAjjM1DQrDgCA6IExpb25l bCBNT1JBTkQ8bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4NCkNjIDogRGVhbiBjaGVu ZzxtYWlsdG86ZGVhbi5jaGVuZ0BodWF3ZWkuY29tPiwgcmFkZXh0QGlldGYub3JnPG1haWx0bzpy YWRleHRAaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQuYXV0 aG9yc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0 LmF1dGhvcnNAaWV0Zi5vcmc+LCBXaW50ZXIgU3RlZmFuPG1haWx0bzpzdGVmYW4ud2ludGVyQHJl c3RlbmEubHU+DQoNCk9uIE1hciAxNiwgMjAxNiwgYXQgMzozMCBQTSwgPGxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbT4gPGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT4gd3JvdGU6DQo+DQo+IEhpIEFs YW4sDQo+DQo+IEkgdGhpbmsgdGhhdCB5b3UgY2FuIGNoZWNrIHRoZSBzZWN0aW9uIDEwLjMuNjoN Cg0KICBTdXJlLiAgVGhhdCBkb2Vzbid0IGZvcmJpZCB1c2luZyBzaW1pbGFyIGFsbG9jYXRpb25z IGluIGRpZmZlcmVudCBwYXJlbnQgYXR0cmlidXRlcy4NCg0KICBBbGFuIERlS29rLg0KDQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= --_000_6B7134B31289DC4FAF731D844122B36E01E03DE6OPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDkxMSI+DQo8c3R5bGU+PCEtLQpodG1sIHsKZm9u dC1mYW1pbHk6IkNvbG9yIEVtb2ppIiwgIkNhbGlicmkiLCAiU2Vnb2UgVUkiLCAiTWVpcnlvIiwg Ik1pY3Jvc29mdCBZYUhlaSBVSSIsICJNaWNyb3NvZnQgSmhlbmdIZWkgVUkiLCAiTWFsZ3VuIEdv dGhpYyIsICJzYW5zLXNlcmlmIjsKfQotLT48L3N0eWxlPjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5 bGU9InRydWUiPjwhLS0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwpt YXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0 Owp9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGlu OwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJz dCwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNw TWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIApwLk1zb0xpc3RQYXJhZ3Jh cGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBkaXYuTXNvTGlzdFBhcmFn cmFwaEN4U3BMYXN0IHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1i b3R0b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7CmxpbmUt aGVpZ2h0OjExNSU7Cn0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxk aXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWls eTogJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScs ICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJztm b250LXNpemU6MTJwdDsiPg0KPGRpdj5JdCBpcyB3aGF0IEkgaGF2ZSB0cnkgdG8gZG8sIHB1dHRp bmcmbmJzcDtJUC1Qb3J0LVR5cGUsIElQLVBvcnQtRXh0LUlQdjQtQWRkciBhdCB0aGUgZmlyc3Qg cGxhY2VzIGJ1dCBpdCBkb2VzIG5vdCBmbHkgd2hlbiBjb25zaWRlcmluZyZuYnNwO0lQLVBvcnQt TG9jYWwtSWQgdGhhdCBpcyBkZWZpbmVkIG9ubHkgaW4gdHdvIG9mIHRoZSB0aHJlZSBhdHRpYnV0 ZXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB5b3UgY29uc2lkZXIgdGhlIFJB RElVUyBhdHRyaWJ1dGUgdHlwZXMgcmVnaXN0cnksIHdoYXQgd291bGQgYmUgeW91ciBjb3VudGVy LXByb3Bvc2FsPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+bGlvbmVsPGJyPg0KPC9k aXY+DQo8ZGl2IGRhdGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+RW52b3nDqSBkZXB1aXMgU3VyZmFjZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy10b3A6IDVweDsgYm9yZGVyLXRvcC1jb2xvcjogcmdi KDIyOSwgMjI5LCAyMjkpOyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5bGU6 IHNvbGlkOyI+DQo8ZGl2Pjxmb250IGZhY2U9IiAnQ2FsaWJyaScsICdTZWdvZSBVSScsICdNZWly eW8nLCAnTWljcm9zb2Z0IFlhSGVpIFVJJywgJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsICdNYWxn dW4gR290aGljJywgJ3NhbnMtc2VyaWYnIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE1cHQ7IGxldHRl ci1zcGFjaW5nOiAwLjAyZW07IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCAmcXVv dDtTZWdvZSBVSSZxdW90OywgJnF1b3Q7TWVpcnlvJnF1b3Q7LCAmcXVvdDtNaWNyb3NvZnQgWWFI ZWkgVUkmcXVvdDssICZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90OywgJnF1b3Q7TWFs Z3VuIEdvdGhpYyZxdW90OywgJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMnB0 OyI+PGI+RGUmbmJzcDs6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzphbGFuZEBmcmVlcmFkaXVz Lm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5BbGFuDQogRGVLb2s8L2E+PGJyPg0KPGI+RW52b3nDqSZu YnNwOzo8L2I+Jm5ic3A74oCObWVyY3JlZGnigI4g4oCOMTbigI4g4oCObWFyc+KAjiDigI4yMDE2 IOKAjjIw4oCOOuKAjjM1PGJyPg0KPGI+w4AgOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86bGlv bmVsLm1vcmFuZEBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9wYXJlbnQiPkxpb25lbCBNT1JBTkQ8L2E+ PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpkZWFuLmNoZW5nQGh1 YXdlaS5jb20iIHRhcmdldD0iX3BhcmVudCI+RGVhbiBjaGVuZzwvYT4sDQo8YSBocmVmPSJtYWls dG86cmFkZXh0QGlldGYub3JnIiB0YXJnZXQ9Il9wYXJlbnQiPnJhZGV4dEBpZXRmLm9yZzwvYT4s IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQuYXV0 aG9yc0BpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij4NCmRyYWZ0LWlldGYtcmFkZXh0LWlwLXBv cnQtcmFkaXVzLWV4dC5hdXRob3JzQGlldGYub3JnPC9hPiwgPGEgaHJlZj0ibWFpbHRvOnN0ZWZh bi53aW50ZXJAcmVzdGVuYS5sdSIgdGFyZ2V0PSJfcGFyZW50Ij4NCldpbnRlciBTdGVmYW48L2E+ PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9IiI+DQo8 ZGl2IGlkPSJyZWFkaW5nUGFuZUJvZHlDb250ZW50Ij5PbiBNYXIgMTYsIDIwMTYsIGF0IDM6MzAg UE0sICZsdDtsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20mZ3Q7ICZsdDtsaW9uZWwubW9yYW5kQG9y YW5nZS5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBBbGFuLDxicj4NCiZn dDsgPGJyPg0KJmd0OyBJIHRoaW5rIHRoYXQgeW91IGNhbiBjaGVjayB0aGUgc2VjdGlvbiAxMC4z LjY6PGJyPg0KPGJyPg0KJm5ic3A7IFN1cmUuJm5ic3A7IFRoYXQgZG9lc24ndCBmb3JiaWQgdXNp bmcgc2ltaWxhciBhbGxvY2F0aW9ucyBpbiBkaWZmZXJlbnQgcGFyZW50IGF0dHJpYnV0ZXMuPGJy Pg0KPGJyPg0KJm5ic3A7IEFsYW4gRGVLb2suPGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_6B7134B31289DC4FAF731D844122B36E01E03DE6OPEXCLILM43corp_-- From nobody Wed Mar 16 13:08:35 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD7712D6F7; Wed, 16 Mar 2016 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QJ-G6gVrEpU; Wed, 16 Mar 2016 13:08:28 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 373C312D707; Wed, 16 Mar 2016 13:08:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 850DFD90; Wed, 16 Mar 2016 20:08:26 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 358PG8pg0tqz; Wed, 16 Mar 2016 20:08:26 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id C1B4FC6F; Wed, 16 Mar 2016 20:08:25 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F1C1D7B5-DAA1-4806-A294-0B053D858A21"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Alan DeKok In-Reply-To: <301_1458158674_56E9BC52_301_7692_1_6B7134B31289DC4FAF731D844122B36E01E03DE6@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Wed, 16 Mar 2016 16:08:32 -0400 Message-Id: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> < 301_1458158674_56E9BC52_301_7692_1_6B7134B31289DC4FAF731D844122B36E01E03DE6@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Dean cheng , "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 20:08:34 -0000 --Apple-Mail=_F1C1D7B5-DAA1-4806-A294-0B053D858A21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 16, 2016, at 4:04 PM, = wrote: >=20 > 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. --Apple-Mail=_F1C1D7B5-DAA1-4806-A294-0B053D858A21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW6b1AAAoJEH0Oec13Yh7NBnoH/jGuF6acm4im6NXrLxMinivu EFTaX8HSTtZ3zhyPwXnSqWIaJcxvlIiAuM5eElIAsg6b93LCbQv+dpzP1F18OqOH 4tZYt00OfE3xx6NiHPHDm8UOmarAACEl9IlLuMe7nOxy+F+/8m3+lqb+pLibRlia F2D/7LLj9SeTFrNqJlBXXl/HwH+6f9+sotu3IDjBjXG5ibhWOpYUsVv76vYg3I5e nCKiCsoo5nY4r0cNvciVdaugoaCHYw6yS/IGqzwpBienZCgTRFK9pcCgr4MU9XfL Ex8+KWEBKGYDK8HmaLcPmRe32GABBzKWRPdjgwLfuMpGwip3OR2PULNfIJKOhSM= =BOPF -----END PGP SIGNATURE----- --Apple-Mail=_F1C1D7B5-DAA1-4806-A294-0B053D858A21-- From nobody Thu Mar 17 02:31:21 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB812D804; Thu, 17 Mar 2016 02:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm88tuK5oRlr; Thu, 17 Mar 2016 02:31:14 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9F612D6A6; Thu, 17 Mar 2016 02:31:14 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id CF8CD403C2; Thu, 17 Mar 2016 10:31:12 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 9A481120059; Thu, 17 Mar 2016 10:31:12 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Thu, 17 Mar 2016 10:31:12 +0100 From: To: Alan DeKok Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSgGiVdLwAByVdPAAAU2XAAA3k7RgAADM0YAApJVVgABSMX/QAATexIAAAqIqT///8JQAgAAY1dj///BaAP//Fkjw Date: Thu, 17 Mar 2016 09:31:11 +0000 Message-ID: <3728_1458207072_56EA7960_3728_8916_21_6B7134B31289DC4FAF731D844122B36E01E04651@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> < 301_1458158674_56E9BC52_301_7692_1_6B7134B31289DC4FAF731D844122B36E01E03DE6@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Dean cheng , "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 09:31:16 -0000 Hi Alan, I know that it is not a perfect solution but having fixed values for sub-TL= V 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 i= t will be a nightmare for IANA allocation as you will have to put as reserv= ed values for the parent attributes not using the sub-TLV. Any allocation o= f 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 de= fine up to 253 per parent attribute, even if the counterpart is that the sa= me "attribute" may have different identifiers and names if reused in multip= le attributes. As you said, it would different if we had a flat code value range with enou= gh values to allocate unique number for sub-TLV, as with Diameter. But we h= ave to face with the existing constraints in RADIUS and I think that the ex= tra-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 > -----Message d'origine----- > De=A0: Alan DeKok [mailto:aland@freeradius.org] > Envoy=E9=A0: mercredi 16 mars 2016 21:09 > =C0=A0: MORAND Lionel IMT/OLN > Cc=A0: Dean cheng; radext@ietf.org; draft-ietf-radext-ip-port-radius- > ext.authors@ietf.org; Winter Stefan > Objet=A0: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radiu= s-06 >=20 > On Mar 16, 2016, at 4:04 PM, > wrote: > > > > It is what I have try to do, putting IP-Port-Type, IP-Port-Ext-IPv4-Add= r at > the first places but it does not fly when considering IP-Port-Local-Id th= at is > defined only in two of the three attributes. >=20 > There's no perfect solution. If there was one, we'd be using Diameter,= not > RADIUS. :) >=20 > In this case, the main push from me is that a TLV called "foo" should h= ave > 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: >=20 > ATTRIBUTE TLV-IP-Port-1 2 > ATTRIBUTE TLV-IP-Port-2 5 > ATTRIBUTE TLV-IP-Port-3 9 >=20 > With all of them having the same meaning, but different parent attribut= es... > and different TLV-Type values. >=20 > It would be less confusing to have them all as the same value. >=20 > > If you consider the RADIUS attribute types registry, what would be your > counter-proposal? >=20 > Sparse allocation is fine. >=20 > Alan DeKok. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Thu Mar 17 05:53:50 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9C12D803; Thu, 17 Mar 2016 05:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU4Nrbyvw66m; Thu, 17 Mar 2016 05:53:47 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEDF12DC03; Thu, 17 Mar 2016 05:52:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8F6A920B38; Thu, 17 Mar 2016 08:49:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U5HTEwGb8BM; Thu, 17 Mar 2016 08:49:54 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-133-245-84.hsd1.ma.comcast.net [50.133.245.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 17 Mar 2016 08:49:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BA5E6881DE; Thu, 17 Mar 2016 08:52:26 -0400 (EDT) From: Sam Hartman To: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> <3728_1458207072_56EA7960_3728_8916_21_6B7134B31289DC4FAF731D844122B36E01E04651@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Thu, 17 Mar 2016 08:52:26 -0400 In-Reply-To: <3728_1458207072_56EA7960_3728_8916_21_6B7134B31289DC4FAF731D844122B36E01E04651@OPEXCLILM43.corporate.adroot.infra.ftgroup> (lionel morand's message of "Thu, 17 Mar 2016 09:31:11 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Dean cheng , "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , Alan DeKok , Winter Stefan Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:53:49 -0000 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 nobody Thu Mar 17 06:11:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F1612D913; Thu, 17 Mar 2016 06:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG3rqGt5KdRI; Thu, 17 Mar 2016 06:11:08 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB1012D546; Thu, 17 Mar 2016 06:10:43 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id EEE7EC03FF; Thu, 17 Mar 2016 14:10:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id B7C8E1A005D; Thu, 17 Mar 2016 14:10:41 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Thu, 17 Mar 2016 14:10:41 +0100 From: To: Sam Hartman Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AQHRgEvbJiztomTRTPeDnJJtYoXTSp9dmy0w Date: Thu, 17 Mar 2016 13:10:41 +0000 Message-ID: <3663_1458220241_56EAACD1_3663_2373_1_6B7134B31289DC4FAF731D844122B36E01E04B82@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> <3728_1458207072_56EA7960_3728_8916_21_6B7134B31289DC4FAF731D844122B36E01E04651@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Dean cheng , "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , Alan DeKok , Winter Stefan Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:11:14 -0000 Hi Sam, I agree. A time slot has been already reserved for discussion on the draft-ietf-rade= xt-ip-port-radius at the next IETF meeting. We could either use this slot to go on this discussion during the meeting o= r have a specific slot for this topic. Any additional feedback is welcome on the mailing list before the meeting. Regards, Lionel > -----Message d'origine----- > De=A0: Sam Hartman [mailto:hartmans@painless-security.com] > Envoy=E9=A0: jeudi 17 mars 2016 13:52 > =C0=A0: MORAND Lionel IMT/OLN > Cc=A0: Alan DeKok; Dean cheng; radext@ietf.org; Winter Stefan; draft-ietf- > radext-ip-port-radius-ext.authors@ietf.org > Objet=A0: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radiu= s-06 >=20 > I think Alan has an important point here. > I think it would be worth some time looking at sharing namespaces for TLV= s. > I think this issue is worth a bit of exploration. >=20 > In more formal language, Alan has raised a technical objection that it wo= uld > be desirable to share namespaces for implementation simplicity. > Lionel has raised an objection that creates administrative complexity. >=20 > I don't think either of these has been adequately explored, and so I thin= k it is > worth the WG's time to explore. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Thu Mar 17 06:37:10 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5017812DAAE; Thu, 17 Mar 2016 06:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZKUGyerH5Zj; Thu, 17 Mar 2016 06:36:52 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E1D12DAC2; Thu, 17 Mar 2016 06:36:50 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4FA6743AE8; Thu, 17 Mar 2016 14:36:49 +0100 (CET) To: Sam Hartman , lionel.morand@orange.com References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> <3728_1458207072_56EA7960_3728_8916_21_6B7134B31289DC4FAF731D844122B36E01E04651@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56EAB2F1.1060100@restena.lu> Date: Thu, 17 Mar 2016 14:36:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KBKXs5kSQ066h6brBeSFw3bk6aWLceh67" Archived-At: Cc: Dean cheng , "radext@ietf.org" , Alan DeKok , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:36:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KBKXs5kSQ066h6brBeSFw3bk6aWLceh67 Content-Type: multipart/mixed; boundary="gujsKmecBxSJAtXT65AVQBR7nAACNjbCE" From: Stefan Winter To: Sam Hartman , lionel.morand@orange.com Cc: Alan DeKok , Dean cheng , "radext@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" Message-ID: <56EAB2F1.1060100@restena.lu> Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> <3728_1458207072_56EA7960_3728_8916_21_6B7134B31289DC4FAF731D844122B36E01E04651@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: --gujsKmecBxSJAtXT65AVQBR7nAACNjbCE Content-Type: multipart/mixed; boundary="------------080102060107080406050205" This is a multi-part message in MIME format. --------------080102060107080406050205 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Hi, > 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. >=20 > 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. >=20 > I don't think either of these has been adequately explored, and so I > 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 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------080102060107080406050205 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------080102060107080406050205-- --gujsKmecBxSJAtXT65AVQBR7nAACNjbCE-- --KBKXs5kSQ066h6brBeSFw3bk6aWLceh67 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW6rLxAAoJEMDeajWKOdxmWKIQAIsKW8QWT8HLcUprIy3WoAHm 8LX9ThDfd7tWhvJlXzgFkik6OSohHF1u1mLvqjrhJGegixd8yEY0jGfGcf49/ZED M4iutbTfWyuU5fqJtC4PattWFvJbYSpE18c4Y8dRooQt6OTZkUHjNNSWhXivS7jq COkvWf4pJtFPjpLplqlCJHav8FIBEfI/8TymlxQtMFchJ33w/aKoJPBDCQVRo5LD tMG6VD/TdJROz1K758B0/TLFk74S0izsGq8Fl0XIVpLbodFJ+K33kxN6Efc1ObYH D7Tv7F3bQLMHW73l/E+yy83h7G464M5Fou9MxTQT2ddSJaH4cPr+2JM4b/jajCuk 6DYAFZz+g9AUqX2xCCDSkDxh7Y7tEQRB/LcPgTRY1tgephDW/SPGu3PONZWIDg0M OwxiEMs5AG+J7H5Ry5QJyEw5W/hVp06qpx+w7ci1GqoA6agEPsZSEeIRV2HHoEk4 MX9VVqS2nNRC2un6zdbQIxYshRxbdX2HI+tgRR6Q82Y2uAIwgC5Bt7TReFLKrHwE 18ngEbnZjt2JQdTNykWaYhTZBQaNYHsBKtTw7uXNS4i+z4BGvU2Kwl71Uk2ovpiL cF3aCo1lAPMWUKQiNIptD1+yRIkt5aVwD9YIRBy+3YgyBX+MWIXVbdgYJ9BjgexH ysfflKAbDD5gIn6vZLJv =TSH9 -----END PGP SIGNATURE----- --KBKXs5kSQ066h6brBeSFw3bk6aWLceh67-- From nobody Thu Mar 17 07:02:41 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA1012D958 for ; Thu, 17 Mar 2016 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiQ7tGUZEd7w for ; Thu, 17 Mar 2016 07:02:31 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1FE312D519 for ; Thu, 17 Mar 2016 07:02:28 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id DF0B543AF5 for ; Thu, 17 Mar 2016 15:02:26 +0100 (CET) To: radext@ietf.org References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> < 301_1458158674_56E9BC52_301_7692_1_6B7134B31289DC4FAF731D844122B36E01E03DE6@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56EAB8F2.5040003@restena.lu> Date: Thu, 17 Mar 2016 15:02:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OLpUTGesBBINI7sCtmpn2Vf0kG2Hge8tI" Archived-At: Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 14:02:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OLpUTGesBBINI7sCtmpn2Vf0kG2Hge8tI Content-Type: multipart/mixed; boundary="TsSF9i9RG2A1xhqQ9QV6sTaRpoclNWr2F" From: Stefan Winter To: radext@ietf.org Message-ID: <56EAB8F2.5040003@restena.lu> Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> < 301_1458158674_56E9BC52_301_7692_1_6B7134B31289DC4FAF731D844122B36E01E03DE6@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: --TsSF9i9RG2A1xhqQ9QV6sTaRpoclNWr2F Content-Type: multipart/mixed; boundary="------------060808040902050701070608" This is a multi-part message in MIME format. --------------060808040902050701070608 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, as an individual: > 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. Ther= e is enough space to do sparse allocation. And it would be confusing to = see a dictionary like: >=20 > ATTRIBUTE TLV-IP-Port-1 2 > ATTRIBUTE TLV-IP-Port-2 5 > 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 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------060808040902050701070608 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------060808040902050701070608-- --TsSF9i9RG2A1xhqQ9QV6sTaRpoclNWr2F-- --OLpUTGesBBINI7sCtmpn2Vf0kG2Hge8tI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW6rjyAAoJEMDeajWKOdxmAAoP/jWqO4xry7eiBF0ucCI0QLGb RxNwTtmHANrV+liR3gh8eVCIleSuBwjHMOUfZxm5yB+kdBdpazcANn7LqmeWdovK gt7pJasQ5ONMJ4gSLKM7vTjRcd83Jn4jaT5pcRhRz9T8QnRI16xg++PelqzyB8mK 7so90mciI9fyX1W5z1z1tSuSgpnjx1I37e3HsE2nz/af1gglMg26xks+pxGU/7TA dX4bVlYeOTqes/ZJC2xZFMLG/+b2WZ4ggUuF5kTRcmVgL6wEnxRxJmUKn5uZuY/y NaMbC/qkZ4QRE+kftRQJ6/gAg5rkW+uFGbi/4Cxc3axobwClJ8irqrkaj5n4Waf7 fnFAZcJfueVLodkAiOium5xGCoQbbJ37uhb8eAjGJhHHMg+ukzweu9yPhBndzXq4 aUjJSpSgWs2sXIFlu4RUnEi04GYGw7oJ/1CGzB7f0Lx3n0C3Z3mhYOVHFv8Iseam rtxMAu+XhlPxY0BpNuCAOLloJaZzC6IFUwERgskZ1/6S3hqSaC3uim3+CiE+bRFD oD54I3wWAAPrm00JArzzTRSvnTG0J7uxw/YwSnV3SUOWNuSuzzAMYQ9fxtvFKGFs HEJ4ewtQSbglQuM3Go5i9AaboPZq90L4vhTRle0RLMWptrp4tGmxOy0mEfdgEiHt IILhr2FlA7H9258RqB3e =EqmO -----END PGP SIGNATURE----- --OLpUTGesBBINI7sCtmpn2Vf0kG2Hge8tI-- From nobody Thu Mar 17 08:03:31 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4729812D860 for ; Thu, 17 Mar 2016 08:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BezqK29rpw1b for ; Thu, 17 Mar 2016 08:03:23 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4F712D978 for ; Thu, 17 Mar 2016 08:03:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id B4F3CD25; Thu, 17 Mar 2016 15:03:22 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xmCieq0Gxl4; Thu, 17 Mar 2016 15:03:22 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 2E7846BA; Thu, 17 Mar 2016 15:03:22 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56EAB8F2.5040003@restena.lu> Date: Thu, 17 Mar 2016 11:03:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <102C4F92-B0A7-485D-A047-B002137BB7C3@deployingradius.com> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> < 301_1458158674_56E9BC52_301_7692_1_6B7134B31289DC4FAF731D844122B36E01E03DE6@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56EAB8F2.5040003@rest ena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:03:30 -0000 On Mar 17, 2016, at 10:02 AM, Stefan Winter = wrote: >=20 > 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? 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. > If the only ones confused are those *writing* the dictionaries then I > 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).=20 Alan DeKok. From nobody Thu Mar 17 08:07:43 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7512DC15 for ; Thu, 17 Mar 2016 08:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAPd_jKBXSPU for ; Thu, 17 Mar 2016 08:07:35 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A101A12DC0F for ; Thu, 17 Mar 2016 08:07:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E02F020B26; Thu, 17 Mar 2016 11:04:57 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t82mCVoA8XqK; Thu, 17 Mar 2016 11:04:57 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 17 Mar 2016 11:04:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8EB8B881DE; Thu, 17 Mar 2016 11:07:33 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56EAB8F2.5040003@restena.lu> Date: Thu, 17 Mar 2016 11:07:33 -0400 In-Reply-To: <56EAB8F2.5040003@restena.lu> (Stefan Winter's message of "Thu, 17 Mar 2016 15:02:26 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:07:41 -0000 >>>>> "Stefan" == Stefan Winter 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 nobody Thu Mar 17 08:58:52 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E00112D577 for ; Thu, 17 Mar 2016 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyQSqV9d229z for ; Thu, 17 Mar 2016 08:58:49 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1841412D5CA for ; Thu, 17 Mar 2016 08:58:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 78FF4A6B; Thu, 17 Mar 2016 15:58:48 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax0Adyfq4Ay7; Thu, 17 Mar 2016 15:58:48 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id A657776A; Thu, 17 Mar 2016 15:58:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 17 Mar 2016 11:58:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62A679B5-F4F6-4970-A170-6193F5D92951@deployingradius.com> References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <9267_1458151631_56E9A0CF_9267_2916_1_6B7134B31289DC4FAF731D844122B36E01E03B90@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24694_1458156652_56E9B46C_24694_4568_1_6B7134B31289DC4FAF731D844122B36E01E03D58@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56EAB8F2.5040003@restena.lu> To: Sam Hartman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:58:51 -0000 On Mar 17, 2016, at 11:07 AM, Sam Hartman = wrote: > 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. That, too. > 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. >=20 > Alan, have I got that right? Yes. Alan DeKok. From nobody Thu Mar 17 17:11:26 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B691312DDF5; Thu, 17 Mar 2016 17:11:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318001124.28062.72279.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 17:11:24 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-09.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 00:11:24 -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-09.txt Pages : 36 Date : 2016-03-17 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 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-09 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/ From nobody Thu Mar 17 17:24:46 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5281E12D68C; Thu, 17 Mar 2016 17:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFpspybxHYXQ; Thu, 17 Mar 2016 17:24:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EE212DD0B; Thu, 17 Mar 2016 17:24:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKY25198; Fri, 18 Mar 2016 00:24:39 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Mar 2016 00:24:38 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.126]) by SJCEML702-CHM.china.huawei.com ([169.254.4.137]) with mapi id 14.03.0235.001; Thu, 17 Mar 2016 17:24:33 -0700 From: Dean cheng To: Alan DeKok Thread-Topic: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 Thread-Index: AQHRe8mlG33G0jkBW0SZ6xQgiSGpU59ZvDXwgAMRfoCAAZGUUA== Date: Fri, 18 Mar 2016 00:24:33 +0000 Message-ID: References: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4493_1457623365_56E19145_4493_7321_1_6B7134B31289DC4FAF731D844122B36E01DFD287@OPEXCLILM43.corporate.adroot.infra.ftgroup> <24401_1457720660_56E30D54_24401_7725_1_6B7134B31289DC4FAF731D844122B36E01DFEA8E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <38D3195C-19FC-4F38-870A-01F03A94E368@freeradius.org> <3B82A79F-E148-4033-9AC2-917221D189B5@freeradius.org> In-Reply-To: <3B82A79F-E148-4033-9AC2-917221D189B5@freeradius.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56EB4AC8.00A0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.126, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8f4c69e958cd4a4c6de32f0a8d69c028 Archived-At: Cc: "radext@ietf.org" , Winter Stefan , "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 00:24:45 -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 > -----Original Message----- > From: Alan DeKok [mailto:aland@freeradius.org] > Sent: Wednesday, March 16, 2016 10:19 AM > To: Dean cheng > Cc: lionel.morand@orange.com; radext@ietf.org; draft-ietf-radext-ip-port- > radius-ext.authors@ietf.org; Winter Stefan > Subject: Re: [radext] Shepherd review of draft-ietf-radext-ip-port-radius= - > 06 >=20 > On Mar 14, 2016, at 9:42 PM, Dean cheng wrote: > > > > 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. >=20 > That's good. >=20 > I'd also suggest adding a note in Section 3.2 that the TLVs the same > numbering, for simplicity. >=20 > from: >=20 > 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]. >=20 > to: >=20 > 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. >=20 > Section 3.2.1 has: >=20 > TLV-Type >=20 > 1. This MUST uniquely refer to the IPFIX Information Element > identifier TBAx1. >=20 > I suggest moving the explanatory sentence elsewhere, such as the > Description field. The TLV-Type content should just be a single digit "1= ". >=20 > Similar comments apply to the other TLVs. >=20 >=20 > 3.2.2. IP-Port-Limit TLV >=20 > Length >=20 > 6. >=20 > I suggest removing the "." for consistency. >=20 >=20 > The description fields for TLVs have text like: >=20 > ... 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]). >=20 > I suggest updating that to: >=20 > This attribute carries IPFIX Information Element 230, "natEvent", > which is a flag to indicate an action > of NAT operation (refer to [IPFIX]). >=20 >=20 > I think my comments are little more than nit picks and minor > clarifications at this point. :) From nobody Mon Mar 21 02:28:45 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798C712D5C2 for ; Mon, 21 Mar 2016 02:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG_8ehlE4EHZ for ; Mon, 21 Mar 2016 02:28:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11A012D4FF for ; Mon, 21 Mar 2016 02:28:42 -0700 (PDT) Received: from localhost ([::1]:33308 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ahw8c-0000sP-Pr; Mon, 21 Mar 2016 02:28:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 21 Mar 2016 09:28:38 -0000 X-URL: https://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/198 Message-ID: <066.26d096299c5aef68d5a33f996b6b4144@trac.tools.ietf.org> X-Trac-Ticket-ID: 198 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20160321092842.C11A012D4FF@ietfa.amsl.com> Resent-Date: Mon, 21 Mar 2016 02:28:42 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: [radext] #198 (bigger-packets): track secdir review comments X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 09:28:44 -0000 #198: track secdir review comments Paul Wouters: I'm a little confused about when a size refers to a RADIUS packet size, and when it refers to a TCP packet size. eg: An implementation of [RFC6613] will silently discard any packet larger than 4096 octets and will close the TCP connection. But TCP is a stream, so it could be using multiple packets smaller than 4096 that would transport a radius packet that is larger than 4096 bytes. (I assume in the beginning it couldn't since everything was limited by single UDP packets?) What does "maximum size of a response" refer to? TCP packet size or radius packet size? I think it would make the document clearer if the authors would go over all mentions of "packet" and "size" and specifically write it out as radius packet size or TCP packet size. I'm also confused by: Other attributes or configuration MAY be used as an indicator that large responses are likely to be acceptable. Are those attributes defined in another RFC? If not, this document should not hand-wave about non-standard attributes. The security considerations state: These attacks can be entirely mitigated by using TLS. If these attacks are acceptable, then this specification can be used over TCP. This text is confusing. I think it means to say "These attacks can be avoided by using TLS". Because this whole document is about TCP, so there is no case where "this specification" can be used "not over TCP". nits: cloing -> closing? by including the attribute the client indicates -> By including the attribute, the client indicates an next hop -> a next hop -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From nobody Mon Mar 21 07:21:26 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 475EA12D86E; Mon, 21 Mar 2016 07:21:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 07:21:12 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 14:21:12 -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 : Considerations regarding the correct use of EAP-Response/Identity Author : Stefan Winter Filename : draft-ietf-radext-populating-eapidentity-00.txt Pages : 9 Date : 2016-03-21 Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-populating-eapidentity/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-populating-eapidentity-00 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/ From nobody Mon Mar 21 07:29:18 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC2612D744 for ; Mon, 21 Mar 2016 07:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9iiSaNO1eOF for ; Mon, 21 Mar 2016 07:29:14 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A424E12D641 for ; Mon, 21 Mar 2016 07:29:12 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4A6AA43ADF for ; Mon, 21 Mar 2016 15:29:11 +0100 (CET) To: radext@ietf.org References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56F00537.2070802@restena.lu> Date: Mon, 21 Mar 2016 15:29:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iTnox7tlwglqp6IhlfUlLrroWleT6aUao" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 14:29:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iTnox7tlwglqp6IhlfUlLrroWleT6aUao Content-Type: multipart/mixed; boundary="VfsuXiGBSvaGlCJq2GJAgI305WTqrLjek" From: Stefan Winter To: radext@ietf.org Message-ID: <56F00537.2070802@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> In-Reply-To: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> --VfsuXiGBSvaGlCJq2GJAgI305WTqrLjek Content-Type: multipart/mixed; boundary="------------000301010506040003050000" This is a multi-part message in MIME format. --------------000301010506040003050000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, this draft is the follow-up of draft-winter-radext-populating-eapidentity-01, which was adopted as a WG item earlier. The main change is the inclusion of a section "Taxonomy of identities in EAP" which hopefully clears up the previous confusions over which identity is used where. In particular, it makes clear that there are identities (which identify a user) and there are outer identities (which do not). It also talks about how outer identities and EAP-Identity come to be; that they are sometimes derived from inner identities and sometimes explicitly configured. The core bits of it being: EAP-Response/Identity is chosen from the set: * all method-specific outer identities from all configured EAP types supporting the notion of an outer identity union * all method-specific identities from all configured EAP types without the notion of an outer identity and Method-specific outer identities are either * explicitly configured (e.g. string input UI: "Outer Identity") * implicitly configured by copying the actual Method-specific (Inner) Identity * implicitly configured by copying the NAI realm of the Method- specific (Inner) Identity and prefixing it non-configurably with a fixed privacy-preserving local username part like "anonymous" or the empty string (see [RFC7542]) * configured in a mixed way, e.g. using a explicit string input UI for the local part of the outer identity and combining it implicitly with a copy of the NAI realm part of the Method- specific (Inner) Identity Please let me know if this makes things clearer. Let's discuss the next steps for this draft at the meeting (I've reserved 5 min). Greetings, Stefan Winter Am 21.03.2016 um 15:21 schrieb internet-drafts@ietf.org: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the RADIUS EXTensions of the IETF. >=20 > Title : Considerations regarding the correct use of E= AP-Response/Identity > Author : Stefan Winter > Filename : draft-ietf-radext-populating-eapidentity-00.txt > Pages : 9 > Date : 2016-03-21 >=20 > Abstract: > There are some subtle considerations for an EAP peer regarding the > content of the EAP-Response/Identity packet when authenticating with= > EAP to an EAP server. This document describes two such > considerations and suggests workarounds to the associated problems. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-populating-eapidenti= ty/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-radext-populating-eapidentity-00= >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------000301010506040003050000 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------000301010506040003050000-- --VfsuXiGBSvaGlCJq2GJAgI305WTqrLjek-- --iTnox7tlwglqp6IhlfUlLrroWleT6aUao Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW8AU3AAoJEMDeajWKOdxmqlYP/R7ben02IkbxweCjxKEKR1hz jMQeKKsGdwhcq+E3U71IhE+D3zQZ60OVpV71zqj+fDJw7ThygZhxTSDbEWNzFYMe 4DlzMnpG+b84Ysn7bDOAB5HqIqDNToOrY9ikk0VL1OS0GyGatW8sFa2snaGXTJYr 7NSK4wNxMTWGiMgAMu1YqIqmE+nKS4CNp4s4ITrnDkqYkU7EROj8kc4+hV5P1sW1 3EYu0kpufiSSVcO3DuuzbbiDOvX9oPD67c3DqmrWujEYl5dmgGoKup0isfQThYOb d530GzR+MgSdKPxuiCE3gHRwaqD6RtTKCphiIu5u9oo3PKQ9T8cywSmYog8DMYUk CajP0KtdsJa/UhivqtoiG0/ngKc8BjqmNArNLy7YiQwnI5tpuWAKtg3yoaVgeMEe cgcuYvNcwFLMm/qwbG5exxh1r5377NikjQ8FpCu2WsvH3s5BiAk/BqbXGBrc3Bho 2mABIRxst/pPoaUCHv1q7wHG8Io2YjZO2VLd6cWhY3+AGF+14dJp2U6XDQJBP5yi /XTNB5hELtfArpzGydSYqatDrgAObcmrkz6SXgBEwEkf/Xku7FMeEGOQ37UlEwMN aUTPPbFLL+DrkTjHuDlcN9T4SwhlPhr4vaLcm+k9460Z/KnQhpv9PT7SheuSV9+i P1/YEvVF1KjXoK15eVAs =Uw+V -----END PGP SIGNATURE----- --iTnox7tlwglqp6IhlfUlLrroWleT6aUao-- From nobody Mon Mar 21 07:32:04 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3A12D6AC for ; Mon, 21 Mar 2016 07:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbwE4tJsz1nu for ; Mon, 21 Mar 2016 07:32:02 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B47312D64B for ; Mon, 21 Mar 2016 07:32:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8654620B5E; Mon, 21 Mar 2016 10:29:15 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0BXxzj3bdrY; Mon, 21 Mar 2016 10:29:15 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-133-245-84.hsd1.ma.comcast.net [50.133.245.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Mar 2016 10:29:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5A30867AF; Mon, 21 Mar 2016 10:31:58 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> Date: Mon, 21 Mar 2016 10:31:58 -0400 In-Reply-To: <56F00537.2070802@restena.lu> (Stefan Winter's message of "Mon, 21 Mar 2016 15:29:11 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 14:32:04 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Please let me know if this makes things clearer. It's more clear, but I'm not sure it's particularly related to reality. Are there actually methods that have a concept of an outer identity as you describe? From nobody Mon Mar 21 07:42:44 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3812D84D for ; Mon, 21 Mar 2016 07:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKd6XfNSKKsa for ; Mon, 21 Mar 2016 07:42:41 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C978A12D760 for ; Mon, 21 Mar 2016 07:42:40 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7F6A043AE1 for ; Mon, 21 Mar 2016 15:42:39 +0100 (CET) To: radext@ietf.org References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56F0085F.5030009@restena.lu> Date: Mon, 21 Mar 2016 15:42:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LkP0a7bgNWV1tTIooCKNS3E3akNrvUJLQ" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 14:42:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LkP0a7bgNWV1tTIooCKNS3E3akNrvUJLQ Content-Type: multipart/mixed; boundary="w0Sa6WJx04hUKRxSGScD1k6rdUcuQeC7r" From: Stefan Winter To: radext@ietf.org Message-ID: <56F0085F.5030009@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> In-Reply-To: --w0Sa6WJx04hUKRxSGScD1k6rdUcuQeC7r Content-Type: multipart/mixed; boundary="------------060806050801040805050904" This is a multi-part message in MIME format. --------------060806050801040805050904 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > It's more clear, but I'm not sure it's particularly related to reality.= >=20 > Are there actually methods that have a concept of an outer identity as > you describe? I was thinking of PEAP and TTLS: there is an identity for Phase 1 (TLS setup) and there is another in Phase 2 (inside the tunnel). The phase 1 one being the outer; and that is the one used for EAP-Response/Identity as well. Both have implementations which allow to either configure the phase 1 identity explicitly or let the supplicant derive it (well, simply copy) from the phase 2 identity. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------060806050801040805050904 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------060806050801040805050904-- --w0Sa6WJx04hUKRxSGScD1k6rdUcuQeC7r-- --LkP0a7bgNWV1tTIooCKNS3E3akNrvUJLQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW8AhfAAoJEMDeajWKOdxm6gMQALl6AtBKND3yOo8I/AWFgxZk HhuNvMMhlse91V3962tZGnfKBl3OWp/HXnv9+hHs/IkBKcjD0V4teXNrTW7r9bXl MOJM3nsQLi6CMx6vx3kSxZIc2zBvOp94T3+XsyTfZrGUXddNdizlzlcR1U8NXREt ebHHSYrArhPEb3B+mynTYhgmOUWhvl+EQEOUrVIDZEh2PW4rqdGm0CYw5masn0/g yV6UXvInoRBGwh7Y+gm31c6I65uF8bXFrkE7iYWe4wmrtmme45zyOjirvr7UzgGa PoyLJLjyrHg//eJrUYGoggoeuYzFhaBYZxdatqUWtzYweDlUaeinW9BTMX/wYhN4 RiJgkI54rSiGeerpYNDMXcIFfMWs9VWFX89QzujkGJMX/KkRLF4EaTioXxNgq2Za bsTJkMly6LAUGB1GRRmPIqEuN4vGSW0fz4+xiEvkqanSGE2DpUasqtM4U0t9iut6 xhSocR9kdEsJBLKGXrRew35OJUwyVCTTu8ov5qlVwJRVk9E+mcBGK4qwVRB00/gF QMmSHkyWCoou3eXWFhekMahfp8AI/8oQovOB6m9Yzf5FxvkBemaa01erPaDLXSwT E/NyAFDCw/Ws9KCa4MmYdnTedCAM049nsRnyldBBSc8reWWEmQLJLpdD6gAqzfst JxEFirikiVsmWQvxJB45 =iIlj -----END PGP SIGNATURE----- --LkP0a7bgNWV1tTIooCKNS3E3akNrvUJLQ-- From nobody Mon Mar 21 08:45:49 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5713D12D8A5 for ; Mon, 21 Mar 2016 08:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5Upi_mTS5ez for ; Mon, 21 Mar 2016 08:45:44 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CF13312D8C2 for ; Mon, 21 Mar 2016 08:45:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 58264D42; Mon, 21 Mar 2016 15:45:41 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plvmso8FdtSE; Mon, 21 Mar 2016 15:45:41 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 44E6ECF9; Mon, 21 Mar 2016 15:45:40 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56F00537.2070802@restena.lu> Date: Mon, 21 Mar 2016 11:45:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:45:48 -0000 On Mar 21, 2016, at 10:29 AM, Stefan Winter = wrote: > The main change is the inclusion of a section "Taxonomy of identities = in > EAP" which hopefully clears up the previous confusions over which > identity is used where. In particular, it makes clear that there are > identities (which identify a user) and there are outer identities = (which > do not). I suggest referencing RFC 7542, and using it's nomenclature. It = refers to "identifiers", as they identify a user. The strings isn't the = user's "identity". As acknowledged in that document, EAP still uses = "identity". My $0.02 is to use the following terminology: * user identifier - the NAI as per Section 1 of RFC 7542 * realm identifier - an NAI where the username portion is omitted, or is = "anonymous" as per Section 2.4 of RFC 7542. That qualification makes it clear *why* the identifiers are different. = There's no "inner" and "outer" identities. Just an identifier which = says "authentication is related to realm X". Realm X is then capable of = authenticating the user, because it has a user identifier. I think the document also needs a recommendation that all EAP = identities SHOULD use the NAI format. All new EAP methods SHOULD use = UTF-8 for identifiers. I'd like to make those a MUST, but realistically, we can't. > Method-specific outer identities are either >=20 > * explicitly configured (e.g. string input UI: "Outer Identity") >=20 > * implicitly configured by copying the actual Method-specific > (Inner) Identity Along with encoding issues. e.g. EAP-MSCHAPv2 uses a method-specific = identity which is not UTF-8. Copying that field to an outer = EAP-Identity is... problematic, to be polite. > * implicitly configured by copying the NAI realm of the Method- > specific (Inner) Identity and prefixing it non-configurably > with a fixed privacy-preserving local username part like > "anonymous" or the empty string (see [RFC7542]) I would call this the "realm" identifier. And make it clear that the = "outer" EAP-Identity SHOULD map to the "realm identifier", but it = doesn't always... which is why we give them different names. > Please let me know if this makes things clearer. Any attempt to make this clearer is better than the mess we have now. Alan DeKok. From nobody Mon Mar 21 09:10:03 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DE312D7A0 for ; Mon, 21 Mar 2016 09:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJMfRhKGv32s for ; Mon, 21 Mar 2016 09:10:00 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB09A12D556 for ; Mon, 21 Mar 2016 09:10:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id CF21320B57; Mon, 21 Mar 2016 12:07:13 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf91TYHedFrS; Mon, 21 Mar 2016 12:07:12 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-133-245-84.hsd1.ma.comcast.net [50.133.245.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Mar 2016 12:07:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3777D867AF; Mon, 21 Mar 2016 12:09:56 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> Date: Mon, 21 Mar 2016 12:09:56 -0400 In-Reply-To: <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> (Alan DeKok's message of "Mon, 21 Mar 2016 11:45:48 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:10:02 -0000 I am really sad to read this discussion. Unfortunately, I'm moving away from the IETF, and I am not going to have the energy to participate in this, but I think we're going to make a huge mess with this approach. Here are some issues I don't think this captures very well. 1) It's not clear to me that in implementations the phase1/outer identity is really part of a method, so much as part of the EAP stack. At least in TTLS, I don't think the outer identity is ever actually carried in the method payloads, so I'm not actually sure that as a matter of protocol it is a method concept, even if it is carried in method-specific data structures in some implementations. 2) Alan's proposal to use NAI for method identifiers is tempting but seems like a really bad idea to me. It depends a lot of the underlying authentication technology. Trying to shove an X.500 subject, a Kerberos principal, or whatever a concrete implementation of an OAUTH-based EAP method would use into NAI seems like a really bad idea, no matter how convenient it would be for a RADIUS implementation. I'm hoping that someone who will be involved in the working group on an ongoing basis shares my concerns and is willing to champion them. From nobody Mon Mar 21 09:16:09 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77712D89F for ; Mon, 21 Mar 2016 09:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSq-WPDst6Yn for ; Mon, 21 Mar 2016 09:15:59 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F0C12D891 for ; Mon, 21 Mar 2016 09:15:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6A5F020B5E; Mon, 21 Mar 2016 12:13:12 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8umOcVYkzbWB; Mon, 21 Mar 2016 12:13:12 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-133-245-84.hsd1.ma.comcast.net [50.133.245.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Mar 2016 12:13:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BA13B867AF; Mon, 21 Mar 2016 12:15:55 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> Date: Mon, 21 Mar 2016 12:15:55 -0400 In-Reply-To: (Sam Hartman's message of "Mon, 21 Mar 2016 12:09:56 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:16:07 -0000 Hmm, thinknig more. Alan's approach addresses most of my concern. If rather than saying SHOULD use NAI for method identifiers, we could say something like SHOULD use NAI if the method's architecture does not empose some other namespace, I'd be reasonably happy. --Sam From nobody Mon Mar 21 09:21:02 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4716D12D8E6 for ; Mon, 21 Mar 2016 09:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB-lpyemXP5p for ; Mon, 21 Mar 2016 09:20:58 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 480AF12D8AA for ; Mon, 21 Mar 2016 09:20:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id A531D121C; Mon, 21 Mar 2016 16:20:49 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YihtKn0h9M4V; Mon, 21 Mar 2016 16:20:49 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 1AB6ED42; Mon, 21 Mar 2016 16:20:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Mon, 21 Mar 2016 12:20:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:21:00 -0000 On Mar 21, 2016, at 12:09 PM, Sam Hartman = wrote: >=20 > I am really sad to read this discussion. > Unfortunately, I'm moving away from the IETF, and I am not going to = have > the energy to participate in this, but I think we're going to make a > huge mess with this approach. It's EAP and RADIUS. It's already a huge mess. I'd like to have = recommendations for implementors and EAP method designers which aren't = "make the mess worse". > 1) It's not clear to me that in implementations the phase1/outer > identity is really part of a method, so much as part of the EAP stack. I agree. This should be made clearer. i.e. due to the issues you raise below in (2), the outer identifier is = likely NOT method specific, and SHOULD be taken from configuration, not = from the method. > At least in TTLS, I don't think the outer identity is ever actually > carried in the method payloads, so I'm not actually sure that as a > matter of protocol it is a method concept, even if it is carried in > method-specific data structures in some implementations. The outer identity is usually derived from the inner identity. > 2) Alan's proposal to use NAI for method identifiers is tempting but > seems like a really bad idea to me. I agree. > It depends a lot of the underlying > authentication technology. Trying to shove an X.500 subject, a = Kerberos > principal, or whatever a concrete implementation of an OAUTH-based EAP > method would use into NAI seems like a really bad idea, no matter how > convenient it would be for a RADIUS implementation. I agree completely. RADIUS has much the same problem as EAP here. The identity and much = of the authentication credentials are taken from an external source, and = RADIUS / EAP restrictions don't apply to them. The recommendation to use the NAI is really a plea of "PLEASE, = whatever you do, DON'T invent a new user identifier. Use the NAI". The rules should be: - outer identity =3D=3D realm identifier, and SHOULD be taken from = configuration. It SHOULD NOT be taken from the inner method, as there = is no guarantee that the inner identity is even UTF-8 - inner method identity SHOULD be the NAI for new EAP methods, and where = permitted by existing EAP methods - inner method identity SHOULD otherwise be taken from the existing EAP = method, which is likely NOT UTF-8 > I'm hoping that someone who will be involved in the working group on = an > ongoing basis shares my concerns and is willing to champion them. I'll be sad to see you go, and will do my best to champion your views. Alan DeKok. From nobody Mon Mar 21 09:24:16 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69EB12D7BF for ; Mon, 21 Mar 2016 09:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiYC7F06B3wf for ; Mon, 21 Mar 2016 09:24:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567BE12D539 for ; Mon, 21 Mar 2016 09:24:14 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0574D22CAC1; Mon, 21 Mar 2016 17:24:13 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D84B027C067; Mon, 21 Mar 2016 17:24:12 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0279.002; Mon, 21 Mar 2016 17:24:12 +0100 From: To: Sam Hartman , Alan DeKok Thread-Topic: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt Thread-Index: AQHRg30MVpqL6Ri0I0WAtrwzevRNS59j5FSAgAAVaACAABeOioAAAbPdgAABQdA= Date: Mon, 21 Mar 2016 16:24:11 +0000 Message-ID: <32014_1458577452_56F0202C_32014_3769_1_6B7134B31289DC4FAF731D844122B36E01E0707B@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.21.155717 Archived-At: Cc: Winter Stefan , "radext@ietf.org" Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:24:16 -0000 Hi, in principles, I agree with Alan's approach (rely on RFC 7542) and with the= generic guidelines "all EAP identities SHOULD use the NAI format". This gi= ves a clear framework without forbidding exceptions to this rule but with t= he potential related issue(s) not to follow the recommended rule. regards, Lionel > -----Message d'origine----- > De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Sam Hartman > Envoy=E9=A0: lundi 21 mars 2016 17:16 > =C0=A0: Alan DeKok > Cc=A0: Winter Stefan; radext@ietf.org > Objet=A0: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidenti= ty- > 00.txt >=20 > Hmm, thinknig more. >=20 > Alan's approach addresses most of my concern. > If rather than saying SHOULD use NAI for method identifiers, we could say > something like SHOULD use NAI if the method's architecture does not > empose some other namespace, I'd be reasonably happy. >=20 > --Sam >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Tue Mar 22 00:57:09 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702BE12D69F for ; Tue, 22 Mar 2016 00:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5vGH55H8ULj for ; Tue, 22 Mar 2016 00:57:06 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A80F12D68B for ; Tue, 22 Mar 2016 00:57:06 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 93C9B43AD1 for ; Tue, 22 Mar 2016 08:57:04 +0100 (CET) To: radext@ietf.org References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56F0FAD0.2010005@restena.lu> Date: Tue, 22 Mar 2016 08:57:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xx2dh4N3AR6MwmH9ccSACc2642UFmRppu" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 07:57:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xx2dh4N3AR6MwmH9ccSACc2642UFmRppu Content-Type: multipart/mixed; boundary="XM0FALJAlh7dx1f2cttr11pnTHDq6sTgc" From: Stefan Winter To: radext@ietf.org Message-ID: <56F0FAD0.2010005@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> In-Reply-To: --XM0FALJAlh7dx1f2cttr11pnTHDq6sTgc Content-Type: multipart/mixed; boundary="------------040306060608070907050100" This is a multi-part message in MIME format. --------------040306060608070907050100 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Sam, > 1) It's not clear to me that in implementations the phase1/outer > identity is really part of a method, so much as part of the EAP stack. > At least in TTLS, I don't think the outer identity is ever actually > carried in the method payloads, so I'm not actually sure that as a > matter of protocol it is a method concept, even if it is carried in > method-specific data structures in some implementations. It really depends on the point of view, I think. Those outer IDs can be configured per method, and they are dependent on the inner ID of "their" method - they need to have a routing component which matches the inner ID so that the request terminates at the correct EAP server. That makes one outer ID specific to exactly one method, hence my calling it method-specific. It's true that they are not actually used inside the EAP method's payload on the wire; they are rather an abstract property of the EAP method that is solely used to populate the choice of candidates for EAP-Response/Identity and for transmission before the actual EAP method payload is underway. Formulation suggestions warmly welcome. > 2) Alan's proposal to use NAI for method identifiers is tempting but > seems like a really bad idea to me. It depends a lot of the underlying= > authentication technology. Trying to shove an X.500 subject, a Kerbero= s > principal, or whatever a concrete implementation of an OAUTH-based EAP > method would use into NAI seems like a really bad idea, no matter how > convenient it would be for a RADIUS implementation. Yes, I don't like that either; the NAI is a good choice if you have a choice - but there are situations where you don't. I think the later points made in the thread provide a clear insight here: SHOULD, unless your method architecture demands otherwise. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------040306060608070907050100 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040306060608070907050100-- --XM0FALJAlh7dx1f2cttr11pnTHDq6sTgc-- --Xx2dh4N3AR6MwmH9ccSACc2642UFmRppu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW8PrQAAoJEMDeajWKOdxm/0IP/jgRVwC8SkC1A1l9lbqPw6JQ hDCUBPlGFKylexiXH6Z1AfsGvwm6bBLtZEsZZyAz91MwrA63Qqgom/Y9U/Y986lj TPaD0qHxepCAqVF1nu31fVkEzcM0y8skA+6lNznill5ummNWwNzmJy+A5sUcCst7 Cy2EhMqX3OuYm6etehdEi4QS5WYKh0eStGNjDUf9xDUhQ2JqcrVra03AWmNs9KN4 pBcyUa++ijCIWxqMzvkBYZU/X8hEl2lnHWt/cu1Nc0SGmiCGBH8V/kYPQLQSo8tf f7vQZzLbNqYie01HhlongmzK0Tee/z/8q8IkwihyzmvccuUlOY+rxgwS3Fo6oNU6 Cx2FMb7iqbBKBbTRQUYTasUDs+/lXsKNvSWM+JD61IVVF+xc+qFfZxz5GOnCjZSg MlFycJbr+Z6b6FPQKH9t0OybDjTKL+Y2zUJ+aJpRwQenpVBh/Ae/xHNvhPs1Qgyi WcFv4Ih/tqCnSurOcAYd+sUMjkKACvrYG5FQm/UHPxhZr39oL0zaG/OsGCL3zHhu 6enBSfijhhMnLTnjbM/yEQYVw1oNwLxQQ0U+7W1jn0MjA28hmkxSImiR1hNxIhv3 IXJYwg0kjIQR7ArlZksKOm3eXzqo724JuSYc7KDsehDigyK+wYsjuFMZwZYilPuY t8DhGjwtU5kLo7NZq1zC =g3OS -----END PGP SIGNATURE----- --Xx2dh4N3AR6MwmH9ccSACc2642UFmRppu-- From nobody Tue Mar 22 06:39:41 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3728D12D8FA for ; Tue, 22 Mar 2016 06:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L6lJhCe7Hm0 for ; Tue, 22 Mar 2016 06:39:30 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0A612D7E2 for ; Tue, 22 Mar 2016 06:38:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 8B3CC1A57; Tue, 22 Mar 2016 13:38:34 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDOTf70ZiFxq; Tue, 22 Mar 2016 13:38:34 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 04609C9E; Tue, 22 Mar 2016 13:38:33 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <56F0FAD0.2010005@restena.lu> Date: Tue, 22 Mar 2016 09:38:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 13:39:35 -0000 On Mar 22, 2016, at 3:57 AM, Stefan Winter = wrote: > It really depends on the point of view, I think. Those outer IDs can = be > configured per method, and they are dependent on the inner ID of = "their" > method - they need to have a routing component which matches the inner > ID so that the request terminates at the correct EAP server. Define "matches". i.e. how UTF-8 identifiers can be "matched" to = identifiers in other character sets. It's not easy. My $0.02 is that we have to be very careful about terminology here. = And make it clear in the document *why* we're being clear on = terminology. > It's true that they are not actually used inside the EAP method's > payload on the wire; they are rather an abstract property of the EAP > method that is solely used to populate the choice of candidates for > EAP-Response/Identity and for transmission before the actual EAP = method > payload is underway. >=20 > Formulation suggestions warmly welcome. I like my distinction between the "realm identifier" and "user = identifier". The "user identifier" can be method specific, but SHOULD = be the NAI. The "realm identifier" MUST be an NAI with no user name = portion, or a user name of "anonymous". That avoids any "inner" and "outer" discussion, which is also = method-specific. i.e. an EAP method has a "user identifier" which is placed into a = method-specific identity field. An EAP method also has a "realm = identifier", which identifies the realm for which the EAP method is = relevant. Where the EAP method has "inner" and "outer" identities, the = realm identifier MUST be used for the outer identity, and the user = identifier MUST be used for the inner identity. When we re-euse existing terminology for these identifiers, we have to = explain in each case why the EAP-Identity here is not, in fact the same = as the EAP-Identity in another situation... even though they have the = same name. That's confusing. > Yes, I don't like that either; the NAI is a good choice if you have a > choice - but there are situations where you don't. I think the later > points made in the thread provide a clear insight here: SHOULD, unless > your method architecture demands otherwise. And where there are inner/outer identities, the outer identity / realm = identifier MUST be an NAI. Alan DeKok. From nobody Tue Mar 29 02:11:17 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68012D595 for ; Tue, 29 Mar 2016 02:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrpaSzzE-X0a for ; Tue, 29 Mar 2016 02:11:09 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AC612D592 for ; Tue, 29 Mar 2016 02:11:07 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D56BF4396F for ; Tue, 29 Mar 2016 11:11:03 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <56FA46A4.7030607@restena.lu> Date: Tue, 29 Mar 2016 11:11:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7niCFaxSrfbU9tVl3OcvEk4NfojmIXI5a" Archived-At: Subject: [radext] Presentation slides X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 09:11:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7niCFaxSrfbU9tVl3OcvEk4NfojmIXI5a Content-Type: multipart/mixed; boundary="U7GU7Ie712Dn7CER4pCvBucmNnUj3UkkU" From: Stefan Winter To: "radext@ietf.org" Message-ID: <56FA46A4.7030607@restena.lu> Subject: Presentation slides --U7GU7Ie712Dn7CER4pCvBucmNnUj3UkkU Content-Type: multipart/mixed; boundary="------------090806030105070907050709" This is a multi-part message in MIME format. --------------090806030105070907050709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, a gentle reminder: if you are on the agenda and want to show slides, please send them in advance to the chairs. Greetings, Stefan & Lionel --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------090806030105070907050709 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090806030105070907050709-- --U7GU7Ie712Dn7CER4pCvBucmNnUj3UkkU-- --7niCFaxSrfbU9tVl3OcvEk4NfojmIXI5a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBCgAGBQJW+kalAAoJEMDeajWKOdxmHu4P+Iic3dBr5ANrmJfSZAKp/CA4 UjHKl4RqzQ6WXW9EFA9AsIeZQmtHtuiAC72JnyujVDQf2re/83u1w6nuZwESb+et GOTGV+Fvt6YnwuWo9Pkm8Gw1n9tZ/1i0+7d8Wt+X6chea0Ip2ZIzT69KgJCBmYfE S+748HKMLiR00ZE3ROdU6XWmfo4GEJWPLDqUVPY5Qplxp0IwGzy39UCXR5i0dj92 t8yal3CdHDgL+w5rCANZHdEagk7IwPvtz2iv4r3BixjWSqnvB3x0ripvNM5Sw/jA gouO1Bg/Z+KjAPuKgcrG9M3yUDy6Jh7ry5fK99ECnhN4iTtOJM3ufK9n0LujJjzC vocFJVPw0Z2F3IUk+1J7Fd4mWmhN17sd7rmx5X8mF98RQpoidj/yK7rvoN29C6dh x/q89RFRYKGx2vcEUttZ7gvzma9PjcWhj6qdtiEf65rTsuuWx4jfRE/j8Tc4P3T0 XS3CgcMYOhN11HEWFimCQ/CydKl8gsDTZ1x0951zaj+UhtVBHUJtOMWi2EC/TBC8 pmtrE5ftcp0A9+0027G/mpo0CNWmfPRoAM57qAo2HsX/JN0FYl3DsqLwvsAkRj2B 9cUIU+ppYs+IyzslTYchcg05iq9TabLTg0BJ+O+3W9tZ3gTpQOpxhDdQ3212MBKJ X9rn3B1KGjnU7KlWVOQ= =U/O4 -----END PGP SIGNATURE----- --7niCFaxSrfbU9tVl3OcvEk4NfojmIXI5a--