From bclaise@cisco.com Tue Dec 4 01:55:25 2012 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 B768321F8800 for ; Tue, 4 Dec 2012 01:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 024ET-Bv4riR for ; Tue, 4 Dec 2012 01:55:24 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 759AA21F8797 for ; Tue, 4 Dec 2012 01:55:24 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB49tNGs003889; Tue, 4 Dec 2012 10:55:23 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB49tMe6012750; Tue, 4 Dec 2012 10:55:22 +0100 (CET) Message-ID: <50BDC88A.5080705@cisco.com> Date: Tue, 04 Dec 2012 10:55:22 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: draft-ietf-radext-ipv6-access.all@tools.ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------090903020008030100010000" Cc: "radext@ietf.org" Subject: [radext] Fwd: Gen-art review of draft-ietf-radext-ipv6-access-13 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 04 Dec 2012 09:55:25 -0000 This is a multi-part message in MIME format. --------------090903020008030100010000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Authors, Can you please provide a new draft version addressing those comments, and I'll progress this document through the IESG. Regards, Benoit -------- Original Message -------- Subject: Gen-art review of draft-ietf-radext-ipv6-access-13 Date: Fri, 9 Nov 2012 19:20:31 -0500 From: Moriarty, Kathleen To: gen-art@ietf.org , iesg@ietf.org , draft-ietf-radext-ipv6-access.all@tools.ietf.org CC: David.Miles@google.com , sarikaya@ieee.org , wdec@cisco.com , blourdelet@aim.com , gwz@net-zen.net I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-radext-ipv6-access-13 Reviewer: Kathleen Moriarty Review Date: November 9, 2012 IETF LC End Date: Tuesday IESG Telechat date: (if known) Summary: The document is ready with nits. Major issues: Minor issues: Nits/editorial comments: Section 2, first sentence of second paragraph: "a" should be "an" and protocols should be singular with either a or an. In the depicted scenario the NAS may embed an IP addressing protocol (... Section 3.1, first sentence: Address does not need to have a capital "a". Section 3.2, Third paragraph, first sentence, Attribute does not need to have a capital "a" Change from: A summary of the DNS-Server-IPv6-Address Attribute format is given To: A summary of the DNS-Server-IPv6-Address attribute format is given Section 3.3, First sentence: Attribute does not need to be capitalized Section 3.5, Attribute is capitalized here too and does not need to be, recommend searching through the document to replace them all with "attribute". Section 3.6: Section Header, change lower case "attribute" to "Attribute" as all the other section titles are capitalized. The use of "attribute" in the body text of this section is already lower case. Section 4: Change "Attribute" to "attribute" Security Section: The first sentence mischaracterizes the draft. I think it should be something more along the lines of the abstract: >From the security section: "This document describes the use of RADIUS for the purposes of authentication, authorization and accounting in IPv6-enabled networks. " Abstract: "This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. " The following from the idnits report should be resolved: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. --------------090903020008030100010000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Authors,

Can you please provide a new draft version addressing those comments, and I'll progress this document through the IESG.

Regards, Benoit


-------- Original Message --------
Subject: Gen-art review of draft-ietf-radext-ipv6-access-13
Date: Fri, 9 Nov 2012 19:20:31 -0500
From: Moriarty, Kathleen <kathleen.moriarty@emc.com>
To: gen-art@ietf.org <gen-art@ietf.org>, iesg@ietf.org <iesg@ietf.org>, draft-ietf-radext-ipv6-access.all@tools.ietf.org <draft-ietf-radext-ipv6-access.all@tools.ietf.org>
CC: David.Miles@google.com <David.Miles@google.com>, sarikaya@ieee.org <sarikaya@ieee.org>, wdec@cisco.com <wdec@cisco.com>, blourdelet@aim.com <blourdelet@aim.com>, gwz@net-zen.net <gwz@net-zen.net> 


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-radext-ipv6-access-13
Reviewer: Kathleen Moriarty
Review Date: November 9, 2012
IETF LC End Date: Tuesday
IESG Telechat date: (if known)

Summary:  The document is ready with nits.

Major issues:

Minor issues:

Nits/editorial comments:
Section 2, first sentence of second paragraph:
"a" should be "an" and protocols should be singular with either a or an.
In the depicted scenario the NAS may embed an IP addressing protocol (...

Section 3.1, first sentence:
Address does not need to have a capital "a".

Section 3.2, Third paragraph, first sentence,
Attribute does not need to have a capital "a"
Change from: A summary of the DNS-Server-IPv6-Address Attribute format is given
To:  A summary of the DNS-Server-IPv6-Address attribute format is given
 
Section 3.3, First sentence:
Attribute does not need to be capitalized

Section 3.5, Attribute is capitalized here too and does not need to be, recommend searching through the document to replace them all with "attribute".

Section 3.6: Section Header, change lower case "attribute" to "Attribute" as all the other section titles are capitalized.  The use of "attribute" in the body text of this section is already lower case.

Section 4: Change "Attribute" to "attribute"

Security Section:
The first sentence mischaracterizes the draft.  I think it should be something more along the lines of the abstract:
>From the security section:
"This document describes the use of RADIUS for the purposes of
   authentication, authorization and accounting in IPv6-enabled
   networks. "
Abstract: "This document specifies additional IPv6 RADIUS attributes useful in
   residential broadband network deployments. "

The following from the idnits report should be resolved: 
Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 2 instances of too long lines in the document, the longest one
     being 3 characters in excess of 72.

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
     document.



--------------090903020008030100010000-- From bclaise@cisco.com Tue Dec 4 01:56:22 2012 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 3006721F8441 for ; Tue, 4 Dec 2012 01:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdEjQkHuyEeU for ; Tue, 4 Dec 2012 01:56:21 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1188D21F842B for ; Tue, 4 Dec 2012 01:56:20 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB49uJSU004004; Tue, 4 Dec 2012 10:56:19 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB49uJuk013427; Tue, 4 Dec 2012 10:56:19 +0100 (CET) Message-ID: <50BDC8C3.9090206@cisco.com> Date: Tue, 04 Dec 2012 10:56:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "draft-ietf-radext-ipv6-access@tools.ietf.org" References: <80A0822C5E9A4440A5117C2F4CD36A640469F0E9@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640469F0E9@DEMUEXC006.nsn-intra.net> X-Forwarded-Message-Id: <80A0822C5E9A4440A5117C2F4CD36A640469F0E9@DEMUEXC006.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------000703050409010608060307" Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , "radext@ietf.org" Subject: [radext] Fwd: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 04 Dec 2012 09:56:22 -0000 This is a multi-part message in MIME format. --------------000703050409010608060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Authors, Can you please address Mehmet's comments. Regards, Benoit -------- Original Message -------- Subject: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13 Date: Tue, 20 Nov 2012 14:38:15 +0100 From: Ersue, Mehmet (NSN - DE/Munich) To: , I reviewed the draft "RADIUS attributes for IPv6 Access Networks" ( draft-ietf-radext-ipv6-access-13.txt) for its operational impact. Summary: Intended status: Standards Track Current status: Waiting for AD Go-Ahead The document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments, which are: assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. The document follows the standard method for Radius attribute definition. As such the attributes and their configuration has been sufficiently described. I do not see any blocking issues. The document seems to be ready for publication as Proposed Standard. Minor issues: - Section 4.4. Delegated-IPv6-Prefix-Pool I am not a AAA-NAS expert, however section 4.4. defines the Delegated-IPv6-Prefix-Pool attribute containing the name of an assigned pool that SHOULD be used to select an IPv6 delegated prefix for the user on the NAS. But there is no mention of how the pool itself is defined. A reference to the document where this has been specified would be useful for the reader. - There is one nit error (lines 453/454) which needs to be fixed: ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 453 0+ 0+ 0 0 0+ TBA4 Delegated-IPv6-Prefix-Pool 454 0+ 0+ 0 0 0+ TBA5 Stateful-IPv6-Address-Pool - There is one nit warning: == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Cheers, Mehmet _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir --------------000703050409010608060307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Authors,

Can you please address Mehmet's comments.

Regards, Benoit


-------- Original Message --------
Subject: [OPS-DIR] OPS-DIR Review of draft-ietf-radext-ipv6-access-13
Date: Tue, 20 Nov 2012 14:38:15 +0100
From: Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com>
To: <ops-dir@ietf.org>, <draft-ietf-radext-ipv6-access@tools.ietf.org> 


I reviewed the draft "RADIUS attributes for IPv6 Access Networks" (
draft-ietf-radext-ipv6-access-13.txt) for its operational impact. 

Summary:
Intended status: Standards Track
Current status: Waiting for AD Go-Ahead 

The document specifies additional IPv6 RADIUS attributes useful in
residential broadband network deployments, which are:
assignment of a host IPv6 address and IPv6 DNS server address via
DHCPv6; assignment of an IPv6 route announced via router advertisement;
assignment of a named
IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host
DHCPv6 addressing.

The document follows the standard method for Radius attribute
definition. As such the attributes and their configuration has been
sufficiently described.

I do not see any blocking issues.  The document seems to be ready for
publication as Proposed Standard.


Minor issues:

- Section 4.4. Delegated-IPv6-Prefix-Pool

I am not a AAA-NAS expert, however section 4.4. defines the
Delegated-IPv6-Prefix-Pool attribute containing the name of an assigned
pool that SHOULD be used to select an IPv6 delegated prefix for the user
on the NAS. But there is no mention of how the pool itself is defined. A
reference to the document where this has been specified would be useful
for the reader.


- There is one nit error (lines 453/454) which needs to be fixed:

** There are 2 instances of too long lines in the document, the longest
one
     being 3 characters in excess of 72.


453	   0+      0+     0      0         0+      TBA4
Delegated-IPv6-Prefix-Pool
454	   0+      0+     0      0         0+      TBA5
Stateful-IPv6-Address-Pool


- There is one nit warning:

== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
      document.

Cheers, 
Mehmet 


_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir



--------------000703050409010608060307-- From iesg-secretary@ietf.org Tue Dec 4 09:14:31 2012 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 50DDA21F8C59; Tue, 4 Dec 2012 09:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z77PWEaynpNU; Tue, 4 Dec 2012 09:14:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D20F21F8C53; Tue, 4 Dec 2012 09:14:30 -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: 4.36 Message-ID: <20121204171430.4399.19.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 09:14:30 -0800 Cc: radext WG Subject: [radext] WG Action: Rechartered RADIUS EXTensions (radext) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 04 Dec 2012 17:14:31 -0000 The RADIUS EXTensions (radext) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. RADIUS EXTensions (radext) ------------------------------------------------ Current Status: Active Working Group Chairs: Jouni Korhonen Mauricio Sanchez Technical advisors: Paul Congdon Assigned Area Director: Benoit Claise Mailing list Address: radext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/radext Archive: http://www.ietf.org/mail-archive/web/radext/ Charter of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Update and clarification of Network Access Identifiers (RFC4282). This work item will correct and clarify issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. - Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC 2865. Milestones: Done - Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done - SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done - RFC 2486bis submitted as a Proposed Standard RFC Done - RFC 3576 MIBs submitted as an Informational RFC Done - RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done - RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done - RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done - RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done - RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done - RADIUS Design Guidelines submitted as a Best Current Practice RFC Done - RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done - Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done - Status-Server I-D submitted as a Proposed Standard RFC Done - RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Done - RADIUS Crypto-agility Requirements submitted as an Informational RFC Dec 2012 - IPv6 Access I-D submitted as a Proposed Standard RFC Dec 2012 - RFC 4282bis submitted as a Proposed Standard RFC Dec 2012 - Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2012 - Dynamic Discovery I-D submitted as a Proposed Standard RFC Dec 2012 - IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Jan 2013 - RADIUS over DTLS I-D submitted as an Experimental RFC Feb 2013 - RADIUS packet fragmentation submitted as an Experimental RFC From stefan.winter@restena.lu Wed Dec 5 05:52:17 2012 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 A5D1721F8BBB for ; Wed, 5 Dec 2012 05:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrRcRcDQ2UvF for ; Wed, 5 Dec 2012 05:52:17 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id DFF1E21F8BB5 for ; Wed, 5 Dec 2012 05:52:16 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 063E310580; Wed, 5 Dec 2012 14:52:15 +0100 (CET) Received: from [IPv6:2001:a18:1:8:ed1c:4834:be74:5d04] (unknown [IPv6:2001:a18:1:8:ed1c:4834:be74:5d04]) by smtprelay.restena.lu (Postfix) with ESMTPS id E18451057F; Wed, 5 Dec 2012 14:52:14 +0100 (CET) Message-ID: <50BF518A.20107@restena.lu> Date: Wed, 05 Dec 2012 14:52:10 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: radext@ietf.org References: <8013_1352312702_509AA77E_8013_3135_1_6B7134B31289DC4FAF731D844122B36E098517@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <8013_1352312702_509AA77E_8013_3135_1_6B7134B31289DC4FAF731D844122B36E098517@PEXCVZYM13.corporate.adroot.infra.ftgroup> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB3C297EF4C14A4165E4A2E6C" X-Virus-Scanned: ClamAV Cc: lionel.morand@orange.com Subject: Re: [radext] RADEXT WG Last Call: NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 05 Dec 2012 13:52:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB3C297EF4C14A4165E4A2E6C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Lionel, all, > Please consider these comments that are more for clarifications than > highlighting new blocking issues. Thanks a lot for the review of the document! Responses inline: > 1/ It is maybe obvious or defined in another document but the > descriptions of Service tags =93aaa+auth=94, =93aaa+acct=94 and =93aaa+= Dynauth=94 > are missing. I've added definitions and also changes the protocol tag and SRV records definition from flow text into a (short) table each. They look like this in my current working copy: +-----------------+-----------------------------------------+ | Service Tag | Use | +-----------------+-----------------------------------------+ | aaa+auth | RADIUS Authentication, i.e. traffic | | | destined to port UDP/1812 in [RFC2865] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | aaa+acct | RADIUS Accounting, i.e. traffic | | | destined to port UDP/1813 in [RFC2865] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | | | traffic as defined in [RFC5176] | +--------------- --+-----------------------------------------+ Figure 1: List of Service Tags +-----------------+-----------------------------------------+ | Protocol Tag | Use | +-----------------+-----------------------------------------+ | radius.tls | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | radius.dtls | RADIUS transported over DTLS as defined | | | in [I-D.ietf-radext-dtls] | +-----------------+-----------------------------------------+ Figure 2: List of Protocol Tags +-----------------+-----------------------------------------+ | SRV Label | Use | +-----------------+-----------------------------------------+ | _radiustls._tcp | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | _radiustls._udp | RADIUS transported over DTLS as defined | | | in [I-D.ietf-radext-dtls] | +-----------------+-----------------------------------------+ Figure 3: List of Protocol Tags With supporting requests in IANA Considerations to register/reserve all those labels. > 2/ Maybe obvious too but it could be clarified that the SRV prefix > defined in this document corresponds to the =93_Service._Proto=94 part = of an > SRV RR. SRV prefix may have different meanings depending on the reader= =2E =20 I've expanded the sentence in question in my working copy to: This specification defines two SRV prefixes (i.e. two values for the "_service._proto" part of an SRV RR): I hope this clarifies the meaning sufficiently. > 3/ We can find several instances of =93AAA server=94 in the draft. It c= ould > be replaced by RADIUS server that is more accurate, as only RADIUS is > considered. I've replaced all instances I could find with RADIUS server in my working copy. Does this sufficiently address your concerns? If so, I'd like to submit -05 in the coming days; and since these were the only comments in the WGLC I'd then like to get the document to the IESG as soon as possible. After all the new charter states that this should be done by December(!).= 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 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigB3C297EF4C14A4165E4A2E6C 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.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC/UY4ACgkQ+jm90f8eFWb45gCdEI1s1luuL3ADQgteXkdCsC/f XA8AniYIHfXpKKAOHF/zfsYSkeRdw+Ia =aihr -----END PGP SIGNATURE----- --------------enigB3C297EF4C14A4165E4A2E6C-- From stefan.winter@restena.lu Wed Dec 5 05:58:22 2012 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 470E721F88FE for ; Wed, 5 Dec 2012 05:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuhUr4PxjfHi for ; Wed, 5 Dec 2012 05:58:21 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C470221F8860 for ; Wed, 5 Dec 2012 05:58:21 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C4B8D10580; Wed, 5 Dec 2012 14:58:20 +0100 (CET) Received: from [IPv6:2001:a18:1:8:ed1c:4834:be74:5d04] (unknown [IPv6:2001:a18:1:8:ed1c:4834:be74:5d04]) by smtprelay.restena.lu (Postfix) with ESMTPS id B1C9C1057F; Wed, 5 Dec 2012 14:58:20 +0100 (CET) Message-ID: <50BF52FC.4050804@restena.lu> Date: Wed, 05 Dec 2012 14:58:20 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: radext@ietf.org, Lionel Morand References: <8013_1352312702_509AA77E_8013_3135_1_6B7134B31289DC4FAF731D844122B36E098517@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50BF518A.20107@restena.lu> In-Reply-To: <50BF518A.20107@restena.lu> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2BA66CB74FF1494A4F058FE" X-Virus-Scanned: ClamAV Subject: Re: [radext] RADEXT WG Last Call: NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 05 Dec 2012 13:58:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD2BA66CB74FF1494A4F058FE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again, > +-----------------+-----------------------------------------+ > | Service Tag | Use | > +-----------------+-----------------------------------------+ > | aaa+auth | RADIUS Authentication, i.e. traffic | > | | destined to port UDP/1812 in [RFC2865] | > | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | > | aaa+acct | RADIUS Accounting, i.e. traffic | > | | destined to port UDP/1813 in [RFC2865] | > | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | Please forgive this obvious nonsense. It should of course read: | aaa+auth | RADIUS Authentication, i.e. traffic as | | | defined in [RFC2865] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | aaa+acct | RADIUS Accounting, i.e. traffic as | | | defined in [RFC2866] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | Need. More. Coffee. Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigD2BA66CB74FF1494A4F058FE 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.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC/UvwACgkQ+jm90f8eFWZTXQCbBSmWEVyIN7psWqLSJ75m0Gft IZoAnRj2DlMv8cLt4MVGNIuiT8SIpoUK =/2M7 -----END PGP SIGNATURE----- --------------enigD2BA66CB74FF1494A4F058FE-- From bclaise@cisco.com Fri Dec 7 07:53:35 2012 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 9629B21F8A88 for ; Fri, 7 Dec 2012 07:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.825 X-Spam-Level: X-Spam-Status: No, score=-7.825 tagged_above=-999 required=5 tests=[AWL=-2.227, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB2zZO5xEHSf for ; Fri, 7 Dec 2012 07:53:33 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB6B21F87E9 for ; Fri, 7 Dec 2012 07:53:33 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB7FrV59019390; Fri, 7 Dec 2012 16:53:31 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qB7FrSYv029456; Fri, 7 Dec 2012 16:53:30 +0100 (CET) Message-ID: <50C210F8.5060107@cisco.com> Date: Fri, 07 Dec 2012 16:53:28 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "radext@ietf.org" , draft-ietf-radext-radius-extensions@tools.ietf.org References: <50C1CA9F.40100@cisco.com> In-Reply-To: <50C1CA9F.40100@cisco.com> X-Forwarded-Message-Id: <50C1CA9F.40100@cisco.com> Content-Type: multipart/alternative; boundary="------------010803080004040503010606" Subject: [radext] AD review: draft-ietf-radext-radius-extensions X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Dec 2012 15:53:35 -0000 This is a multi-part message in MIME format. --------------010803080004040503010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is my AD review. 3 categories: problems, clarifying questions, and editorial comments _Problems:_ 1. Section 2.1 Length This field is identical to the Length field of the Attribute format defined in[RFC2865] Section 5 . [RFC2865] Section 5 says: Length The Length field is one octet, and indicates the length of this Attribute_including_the Type, Length and Value fields. So the length doesn't include the one octet from Extended-Type, if I read the text correctly! But I see "Permitted values are between_4_ and_255_." So it seems that the Extended-Type length is included when I see 255. Please improve the text. Same remark for the other types. 2. What is the semantic of TLV Data type in section 2.3? I mean: how do we define the relationship between sub-TLV? Always logical AND? Or logical OR, or something else such as nested? Attribute encapsulating two TLVs, one after the other. 241.2 { 1 23 45 } { 2 67 89 } -> f1 0b 02 01 04 23 45 02 04 67 89 What if 241.2 { 1 23 45 } { 1 23 46 } RFC 2865: Some Attributes MAY be included more than once. The effect of this is Attribute specific, and is specified in each Attribute description. A summary table is provided at the end of the "Attributes" section. If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. The order of Attributes of different Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of attributes of different types. A RADIUS server or client MUST NOT require attributes of the same type to be contiguous. What is the impact for sub-TLV? Do you want to have a table like in RFC 2865 section 5.44 with the list of attributes, explaining whether or not they can be part of the sub-TLV, and with which multiplicity. Note: I spent quite some time on structured data semantic with RFC 6313, the IPFIX structured data 3. Section 2.8 When an implementation receives an "invalid attribute", it SHOULD be silently discarded. If it is not discarded, it MUST NOT be handled in the same manner as a well-formed attribute. Section 5.2 Proxy servers SHOULD forward attributes, even ones which they do not understand, or which are not in a local dictionary. Question: what should proxy servers do with invalid attributes? Maybe, clarify "implementation" as it means client and server, and not proxy which should forward "invalid attribute" _Clarifying questions_ 1. What's the max length of Long Extended Type? * defining a method which uses the additional octet to indicate data fragmentation across multiple Attributes. This method provides a standard way for an Attribute to carry more than 253 octets of data. The max length is the one from the RADIUS packet, ie 4K, correct? I propose to mention this. I was wondering what's the link with this new entry in the charter: Feb 2013 RADIUS packet fragmentation submitted as an Experimental RFC Apparently, none. 2. In section 1.1, called "Unmet Requirements", why do you speak about: It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that new specifications use the formats defined in this specification. The alternative to the above recommendations is a circular argument of not implementing this specification because no other standards reference it, and also not defining new standards referencing this specification because no implementations exist. Maybe a new section title for the 2 paragraphs above? 3. For example, Livingston has Vendor-Id 307, and has defined an attribute "IP-Pool" as number 6. This VSA can be uniquely identified as 26.307.6. Don't you want to mention "Livingston-IP-Pool" instead? Similar remark for For example, the company USR has been allocated Vendor-Id 429, and has defined a "Version-Id" attribute as number 32768. This VSA can be uniquely identified as 26.429.32768. 4. Section 2.7.1 We RECOMMEND that vendors use their name as a unique prefix for attribute names. Should RADIUS server implementations follow this rules when receiving attributes, specifically when the same attribute name from different vendors is used. So basically, enforcing global uniqueness of name, and an advice for the RADIUS server. 5. * New specifications SHOULD NOT request allocation from the standard Attribute Type Space (i.e. Attributes 1 through 255). That space is deprecated. Deprecated: is it the right term? Maybe you meant: Assignment from that space is not to be used. In this case, this contradicts * specifications which allocate a small number of attributes (i.e. less than ten) should have all allocations made from the standard space. 6. section 6.7 * RADIUS proxy servers SHOULD forward all attributes, even ones which they do not understand, or which are not in a local dictionary. These attributes SHOULD be forwarded verbatim, with no modifications or changes Why do you repeat what you have written in section 5.2? Proposal: OLD: * RADIUS proxy servers SHOULD forward all attributes, even ones which they do not understand, or which are not in a local dictionary. These attributes SHOULD be forwarded verbatim, with no modifications or changes. * When forwarding attributes, RADIUS proxy servers SHOULD forward the "Reserved" field unchanged. That is, they SHOULD NOT assume that the "Reserved" field can always be set to zero. NEW: * RADIUS proxy servers MUST follow the specifications in section 5.2 8. section 10.3.4 * specifications which allocate a small number of attributes (i.e. less than ten) should have all allocations made from the standard space. * specifications which allocate a large number of attributes (i.e. ten or more) should have all allocations made from the extended space. Instead of using a number, which would anyway not be relevant very long, why don't you have a relative number? For example, instead of "i.e. ten or more", "compared to the remaining available number of entries in the standard space" 9. Section 10.3.4 * specifications which request allocation of an attribute which can transport 253 or more octets of data should have that attribute allocated from within the long extended space, We note thatSection 6.5 , above requires specifications to request this allocation. Are we ever going to face the issue that an attribute is right now below 253, but there is a probability that it could be extended in the future? Do we want to advice that such an attribute be allocated to the long extended space right now? Or do we advice to allocate a separate attribute in the future? _Editorial comments_ 1. Group the entry logically, like for the two entries related to "Extended Type" OLD: * defining a "Long Extended Type" format, which inserts an additional octet between the "Extended Type" octet, and the "Value" field. This method gives us a general way of adding additional functionality to the protocol. * defining a method which uses the additional octet to indicate data fragmentation across multiple Attributes. This method provides a standard way for an Attribute to carry more than 253 octets of data. * allocating 2 attributes as using the format "Long Extended Type". This allocation extends the RADIUS Attribute Type Space by an additional 500 values. NEW: * defining a "Long Extended Type" format, which inserts an additional octet between the "Extended Type" octet, and the "Value" field. This method gives us a general way of adding additional functionality to the protocol. * allocating 2 attributes as using the format "Long Extended Type". This allocation extends the RADIUS Attribute Type Space by an additional 500 values. * defining a method which uses the additional octet to indicate data fragmentation across multiple Attributes. This method provides a standard way for an Attribute to carry more than 253 octets of data. 2. Vendor-Id The 4 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order. Give a reference tohttp://www.iana.org/assignments/enterprise-numbers Note: there are multiple instances of that sentence. 3. Section2.6 . Vendor-ID Field We define the Vendor-ID field of Vendor-Specific Attributes to encompass the entire 4 octets of the Vendor field. [RFC2865 ]Section 5.26 defined it to be 3 octets, with the high octet being zero. This change has no immediate impact on RADIUS, as the maximum Private Enterprise Code defined is still within 16 bits. There is something wrong with the reference: [RFC2865 ]Section 5.26 4. Section2.3.1 . TLV Nesting TLVs may contain other TLVs. When this occurs, the "container" TLV MUST be completely filled by the "contained" TLVs. That is, the "container" TLV-Length field MUST be exactly two (2) more than the sum of the "contained" TLV-Length fields. If the "contained" TLVs over-fill the "container" TLV, the "container" TLV MUST be considered to be an "invalid attribute", and handled as described inSection 2.7 , below. Section 2.7 ->Section 2.8 5. * Specifications of an ttribute which encodes 252 octets or less => attribute 6. In section 1, please introduce with one sentence or two the guidelines in section 6. Actually, it would also fit the abstract. Reason: while I was reading through all these extra encodings, I had a lot questions that were answered in section 6. I could have paid more attention to the table of content, sure but ... 7. section 7 Rationale Rationale for what? "Specifications rationale" maybe? 8. section 10.3.4 * specifications which request allocation of an Attribute of data type TLV should have that attribute allocated from the extended space. Attribute -> attribute 9. This document updates:2865 ,2866 ,3575 ,5176 ,6158 My guess is that those should be normative references Regards, Benoit --------------010803080004040503010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is my AD review.
3 categories: problems, clarifying questions, and editorial comments

Problems:
1. 
Section 2.1
 Length

      This field is identical to the Length field of the Attribute
      format defined in [RFC2865] Section 5. 

[RFC2865] Section 5 says:
Length

      The Length field is one octet, and indicates the length of this
      Attribute including the Type, Length and Value fields. 

So the length doesn't include the one octet from Extended-Type, if I read the text correctly!
But I see "Permitted values are between 4 and 255." So it seems that the Extended-Type length is 
included when I see 255. 
Please improve the text.
Same remark for the other types.


2. 
What is the semantic of TLV Data type in section 2.3?
I mean: how do we define the relationship between sub-TLV?
Always logical AND? Or logical OR, or something else such as nested?

Attribute encapsulating two TLVs, one after the other.

     241.2 { 1 23 45 } { 2 67 89 }
       -> f1 0b 02 01 04 23 45 02 04 67 89

What if 
     241.2 { 1 23 45 } { 1 23 46 }

RFC 2865:
   Some Attributes MAY be included more than once.  The effect of this
   is Attribute specific, and is specified in each Attribute
   description.  A summary table is provided at the end of the
   "Attributes" section.

   If multiple Attributes with the same Type are present, the order of
   Attributes with the same Type MUST be preserved by any proxies.  The
   order of Attributes of different Types is not required to be
   preserved.  A RADIUS server or client MUST NOT have any dependencies
   on the order of attributes of different types.  A RADIUS server or
   client MUST NOT require attributes of the same type to be contiguous.

What is the impact for sub-TLV?
Do you want to have a table like in RFC 2865 section 5.44 with the list 
of attributes, explaining whether or not they can be part of the sub-TLV, and 
with which multiplicity.

Note: I spent quite some time on structured data semantic with RFC 6313, the IPFIX structured data


3. 
Section 2.8
   When an implementation receives an "invalid attribute", it SHOULD be
   silently discarded.  If it is not discarded, it MUST NOT be handled
   in the same manner as a well-formed attribute. 

Section 5.2
   Proxy servers SHOULD forward
   attributes, even ones which they do not understand, or which are not
   in a local dictionary.

Question: what should proxy servers do with invalid attributes?
Maybe, clarify "implementation" as it means client and server, and not proxy which should forward "invalid attribute"


Clarifying questions


1.
What's the max length of Long Extended Type?

   * defining a method which uses the additional octet to indicate data
     fragmentation across multiple Attributes.  This method provides a
     standard way for an Attribute to carry more than 253 octets of
     data.

The max length is the one from the RADIUS packet, ie 4K, correct?
I propose to mention this.
I was wondering what's the link with this new entry in the charter:
Feb 2013   RADIUS packet fragmentation submitted as an Experimental RFC
Apparently, none. 


2. In section 1.1, called "Unmet Requirements", why do you speak about:
   It is RECOMMENDED that implementations support this specification.
   It is RECOMMENDED that new specifications use the formats defined in
   this specification.

   The alternative to the above recommendations is a circular argument
   of not implementing this specification because no other standards
   reference it, and also not defining new standards referencing this
   specification because no implementations exist.

Maybe a new section title for the 2 paragraphs above?

3.
   For example, Livingston has Vendor-Id 307, and has defined an
   attribute "IP-Pool" as number 6.  This VSA can be uniquely identified
   as 26.307.6.

Don't you want to mention "Livingston-IP-Pool" instead?
Similar remark for 
   For example, the company USR has been allocated Vendor-Id 429, and
   has defined a "Version-Id" attribute as number 32768.  This VSA can
   be uniquely identified as 26.429.32768.

4. 
Section 2.7.1
   We RECOMMEND that vendors use their name as a unique prefix for
   attribute names. 

Should RADIUS server implementations follow this rules when receiving attributes, 
specifically when the same attribute name from different vendors is used.
So basically, enforcing global uniqueness of name, and an advice for the RADIUS server.

5. 
   * New specifications SHOULD NOT request allocation from the standard
     Attribute Type Space (i.e. Attributes 1 through 255).  That space
     is deprecated.

Deprecated: is it the right term?
Maybe you meant: Assignment from that space is not to be used.
In this case, this contradicts
      * specifications which allocate a small number of attributes
        (i.e. less than ten) should have all allocations made from
        the standard space.

6. 
section 6.7
   * RADIUS proxy servers SHOULD forward all attributes, even ones
     which they do not understand, or which are not in a local
     dictionary.  These attributes SHOULD be forwarded verbatim, with
     no modifications or changes
Why do you repeat what you have written in section 5.2?

Proposal:
OLD:
   * RADIUS proxy servers SHOULD forward all attributes, even ones
     which they do not understand, or which are not in a local
     dictionary.  These attributes SHOULD be forwarded verbatim, with
     no modifications or changes.

   * When forwarding attributes, RADIUS proxy servers SHOULD forward
     the "Reserved" field unchanged.  That is, they SHOULD NOT assume
     that the "Reserved" field can always be set to zero.
NEW:
   * RADIUS proxy servers MUST follow the specifications in section 5.2
 
	
8.
section 10.3.4
      * specifications which allocate a small number of attributes
        (i.e. less than ten) should have all allocations made from
        the standard space.

      * specifications which allocate a large number of attributes
        (i.e. ten or more) should have all allocations made from the
        extended space.
Instead of using a number, which would anyway not be relevant very long, why don't you have a relative number?
For example, instead of "i.e. ten or more", "compared to the remaining available number of entries in the standard space"
  

9.
Section 10.3.4
      * specifications which request allocation of an attribute
        which can transport 253 or more octets of data should have
        that attribute allocated from within the long extended space,
        We note that Section 6.5, above requires specifications to
        request this allocation.


Are we ever going to face the issue that an attribute is right now below 253, but 
there is a probability that it could be extended in the future?
Do we want to advice that such an attribute be allocated to the long extended space right now?
Or do we advice to allocate a separate attribute in the future?



Editorial comments
1. 
Group the entry logically, like for the two entries related to "Extended Type"
OLD:
   * defining a "Long Extended Type" format, which inserts
     an additional octet between the "Extended Type" octet,
     and the "Value" field.  This method gives us a general way of
     adding additional functionality to the protocol.

   * defining a method which uses the additional octet to indicate data
     fragmentation across multiple Attributes.  This method provides a
     standard way for an Attribute to carry more than 253 octets of
     data.

   * allocating 2 attributes as using the format "Long Extended Type".
     This allocation extends the RADIUS Attribute Type Space
     by an additional 500 values.

NEW:
   * defining a "Long Extended Type" format, which inserts
     an additional octet between the "Extended Type" octet,
     and the "Value" field.  This method gives us a general way of
     adding additional functionality to the protocol.

   * allocating 2 attributes as using the format "Long Extended Type".
     This allocation extends the RADIUS Attribute Type Space
     by an additional 500 values.

   * defining a method which uses the additional octet to indicate data
     fragmentation across multiple Attributes.  This method provides a
     standard way for an Attribute to carry more than 253 octets of
     data.

2. 
Vendor-Id

      The 4 octets are the SMI Network Management Private Enterprise
      Code of the Vendor in network byte order.

Give a reference to http://www.iana.org/assignments/enterprise-numbers
Note: there are multiple instances of that sentence.

3. 
Section 2.6.  Vendor-ID Field

   We define the Vendor-ID field of Vendor-Specific Attributes to
   encompass the entire 4 octets of the Vendor field.  [RFC2865] Section
   5.26 defined it to be 3 octets, with the high octet being zero.  This
   change has no immediate impact on RADIUS, as the maximum Private
   Enterprise Code defined is still within 16 bits.

There is something wrong with the reference: [RFC2865] Section 5.26


4. 
Section 2.3.1.  TLV Nesting
   TLVs may contain other TLVs.  When this occurs, the "container" TLV
   MUST be completely filled by the "contained" TLVs.  That is, the
   "container" TLV-Length field MUST be exactly two (2) more than the
   sum of the "contained" TLV-Length fields.  If the "contained" TLVs
   over-fill the "container" TLV, the "container" TLV MUST be considered
   to be an "invalid attribute", and handled as described in Section
   2.7, below. 

Section 2.7 ->Section 2.8

5.
   * Specifications of an ttribute which encodes 252 octets or less
=> attribute


6. 
In section 1, please introduce with one sentence or two the guidelines in section 6.
Actually, it would also fit the abstract.
Reason: while I was reading through all these extra encodings, I had a lot questions that were answered in section 6. 
I could have paid more attention to the table of content, sure but ...


7. 
section 7 Rationale
Rationale for what? "Specifications rationale" maybe?

8. 
section 10.3.4
      * specifications which request allocation of an Attribute of
        data type TLV should have that attribute allocated from the
        extended space.
Attribute -> attribute

9. 
This document updates: 2865, 2866, 3575, 5176, 6158   
My guess is that those should be normative references


Regards, Benoit
--------------010803080004040503010606-- From jounikor@gmail.com Wed Dec 12 23:47:42 2012 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 2B13F21F864D for ; Wed, 12 Dec 2012 23:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttv25Na0+1oC for ; Wed, 12 Dec 2012 23:47:41 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5598721F87EC for ; Wed, 12 Dec 2012 23:47:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1460488lbk.31 for ; Wed, 12 Dec 2012 23:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=rLX0Z3wfDMBHYeyFdHd4+RMcnPFzWo8uVYh9SMVf6rs=; b=O4TA2YwpINxsmUxSfn5yIJZprQeYVHfQIg/0y5Q8L+UpU15pIaPzEefGgKRxsJtrpl 0KWM+Ky1De2R5mVa7HfF0Bhk0O7aKPA1DfXG76npnMI2E3DW7R/uZAzAaf9jJX5FajJe G+RtpEZuSuN25TWfaokwGYvyQM9AActzyvo0Yb+VQgmWErtCs0JJWD2PERm7T4a0sS3q aChAvHQ4WcxoTcNP3W4APJJOyEyIhFp84hUjK3RfiNBUY9/bjTQ3SxhiyiWQkNi/wPAC kiMDIprOkgDCMM+0fk5yqBHh1CXuazHt+39/qXMvA0qKZ8TBFbqMr5wm8gc2dnDIw3rE Qk+w== Received: by 10.152.111.41 with SMTP id if9mr61406lab.23.1355384860272; Wed, 12 Dec 2012 23:47:40 -0800 (PST) Received: from [192.168.250.35] ([194.100.71.98]) by mx.google.com with ESMTPS id v6sm329427lbf.11.2012.12.12.23.47.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 23:47:38 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Dec 2012 09:47:36 +0200 Message-Id: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> To: radext@ietf.org, "aland@freeradius.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 13 Dec 2012 00:05:15 -0800 Cc: Benoit Claise , "radext-chairs@tools.ietf.org" Subject: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Dec 2012 07:47:42 -0000 Folks, As discussed in Atlanta, we are ready to ask for the WG adoption of = draft-dekok-radext-nai-02 (The Network Access Identifier "bis") starting = today. The plan is that once we have had the adoption call finished we = can move the document straight into WGLC (knowing there are already = reviews done). The WG adoption call ends 20th Dec. This is a quick one week call since = we have had the document around quite long already. If you have concerns = against the document, raise them in the mailing list. Silence will be = counted as acceptance. Of course folks are encouraged to endorse the = document in the mailing list. - Jouni & Mauricio= From internet-drafts@ietf.org Thu Dec 13 06:16:02 2012 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 A165621F8AFC; Thu, 13 Dec 2012 06:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pfchSqP7h9O; Thu, 13 Dec 2012 06:16:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312D121F8AFA; Thu, 13 Dec 2012 06:16:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121213141602.3521.8983.idtracker@ietfa.amsl.com> Date: Thu, 13 Dec 2012 06:16:02 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Dec 2012 14:16:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADI= US/DTLS Author(s) : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-05.txt Pages : 13 Date : 2012-12-13 Abstract: This document specifies a means to find authoritative RADIUS servers for a given realm. It can be used in conjunction with RADIUS/TLS and RADIUS/DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan.winter@restena.lu Thu Dec 13 06:18:10 2012 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 66DEA21F8854 for ; Thu, 13 Dec 2012 06:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL5SG406w32c for ; Thu, 13 Dec 2012 06:18:09 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 743A721F8849 for ; Thu, 13 Dec 2012 06:18:09 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4330C1057F for ; Thu, 13 Dec 2012 15:18:08 +0100 (CET) Received: from [IPv6:2001:a18:1:8:b057:dbe3:c8f1:bc65] (unknown [IPv6:2001:a18:1:8:b057:dbe3:c8f1:bc65]) by smtprelay.restena.lu (Postfix) with ESMTPS id 31D021057E for ; Thu, 13 Dec 2012 15:18:08 +0100 (CET) Message-ID: <50C9E39B.10502@restena.lu> Date: Thu, 13 Dec 2012 15:18:03 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: radext@ietf.org References: <20121213141602.3521.8983.idtracker@ietfa.amsl.com> In-Reply-To: <20121213141602.3521.8983.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig60C25C358210FCADDABE71A3" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Dec 2012 14:18:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60C25C358210FCADDABE71A3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, this document revision takes all the received WGLC comments into account. I believe it is now ready for submission to the IESG. Greetings, Stefan On 13.12.2012 15:16, internet-drafts@ietf.org wrote: >=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 Working Group of th= e IETF. >=20 > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and = RADIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-05.txt > Pages : 13 > Date : 2012-12-13 >=20 > Abstract: > This document specifies a means to find authoritative RADIUS servers= > for a given realm. It can be used in conjunction with RADIUS/TLS an= d > RADIUS/DTLS. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-= 05 >=20 >=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 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig60C25C358210FCADDABE71A3 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.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDJ46AACgkQ+jm90f8eFWaVBQCfbfxOJ12QY8jPmN/zpwMT2yWH 99oAnRBk8+RZ2CTISu3UXkjVRnUykll2 =EVNy -----END PGP SIGNATURE----- --------------enig60C25C358210FCADDABE71A3-- From lionel.morand@orange.com Thu Dec 13 06:22:21 2012 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 3BECF21F8B22 for ; Thu, 13 Dec 2012 06:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05iPg34aQeuI for ; Thu, 13 Dec 2012 06:22:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4A59521F8B0F for ; Thu, 13 Dec 2012 06:22:20 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B2F5F2DC24A; Thu, 13 Dec 2012 15:22:19 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 982154C071; Thu, 13 Dec 2012 15:22:19 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 15:22:19 +0100 From: To: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-05.txt Thread-Index: AQHN2Tyw91sKViYRIEKUsKP7rbcibZgWx5xw Date: Thu, 13 Dec 2012 14:22:18 +0000 Message-ID: <927_1355408539_50C9E49B_927_36_1_6B7134B31289DC4FAF731D844122B36E0C450C@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20121213141602.3521.8983.idtracker@ietfa.amsl.com> <50C9E39B.10502@restena.lu> In-Reply-To: <50C9E39B.10502@restena.lu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Dec 2012 14:22:21 -0000 Hi Stefan, All the small issues raised after my previous review are now closed in this= new version of the draft. Thank for your effort and sorry for this late response. Regards, Lionel -----Message d'origine----- De=A0: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] De la part = de Stefan Winter Envoy=E9=A0: jeudi 13 d=E9cembre 2012 15:18 =C0=A0: radext@ietf.org Objet=A0: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-05.t= xt Hi, this document revision takes all the received WGLC comments into account. I= believe it is now ready for submission to the IESG. Greetings, Stefan On 13.12.2012 15:16, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the RADIUS EXTensions Working Group of the = IETF. >=20 > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RA= DIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-05.txt > Pages : 13 > Date : 2012-12-13 >=20 > Abstract: > This document specifies a means to find authoritative RADIUS servers > for a given realm. It can be used in conjunction with RADIUS/TLS and > RADIUS/DTLS. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-0 > 5 >=20 >=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 -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From aland@freeradius.org Sat Dec 15 09:16:42 2012 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 00DA421F8651 for ; Sat, 15 Dec 2012 09:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJP5gOZgL7kb for ; Sat, 15 Dec 2012 09:16:41 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE9B21F8634 for ; Sat, 15 Dec 2012 09:16:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 95B6F2241715; Sat, 15 Dec 2012 18:16:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWj0iE-KhJmf; Sat, 15 Dec 2012 18:16:34 +0100 (CET) Received: from thor.home (AAnnecy-157-1-160-202.w86-209.abo.wanadoo.fr [86.209.159.202]) by power.freeradius.org (Postfix) with ESMTPSA id 97EB1224044D; Sat, 15 Dec 2012 18:16:34 +0100 (CET) Message-ID: <50CCB073.1090009@freeradius.org> Date: Sat, 15 Dec 2012 18:16:35 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> In-Reply-To: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 15 Dec 2012 12:53:26 -0800 Cc: Benoit Claise , radext@ietf.org, "radext-chairs@tools.ietf.org" Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 17:16:42 -0000 Jouni Korhonen wrote: > Folks, > > As discussed in Atlanta, we are ready to ask for the WG adoption of draft-dekok-radext-nai-02 (The Network Access Identifier "bis") starting today. The plan is that once we have had the adoption call finished we can move the document straight into WGLC (knowing there are already reviews done). > > The WG adoption call ends 20th Dec. This is a quick one week call since we have had the document around quite long already. If you have concerns against the document, raise them in the mailing list. Silence will be counted as acceptance. Of course folks are encouraged to endorse the document in the mailing list. As discusses early, the document should be split in two. My $0.02 is to accept the document as-is, rename it to draft-ietf-radext-naibis-00.txt, and then split it. All of the RADIUS / Diameter text will then be removed, and placed into a second document: draft-iet-radext-naiusage-00.txt The goal is to get the NAI-bis document published quickly. Then, discuss the usage of NAI within RADIUS as a slightly longer-term project. Alan DeKok. From ietf@augustcellars.com Sat Dec 15 16:49:48 2012 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 DE2EA21F853E for ; Sat, 15 Dec 2012 16:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgQCCRNwdpDb for ; Sat, 15 Dec 2012 16:49:48 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66521F8538 for ; Sat, 15 Dec 2012 16:49:48 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 940C238EFB; Sat, 15 Dec 2012 16:49:47 -0800 (PST) From: "Jim Schaad" To: "'Alan DeKok'" , "'Jouni Korhonen'" References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> <50CCB073.1090009@freeradius.org> In-Reply-To: <50CCB073.1090009@freeradius.org> Date: Sat, 15 Dec 2012 16:49:33 -0800 Message-ID: <002301cddb27$37a7e550$a6f7aff0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWeFGOTJIWzFgmWZqFXzUHF4MWqQK8cNZ6mPN6BoA= Content-Language: en-us Cc: 'Benoit Claise' , radext@ietf.org, radext-chairs@tools.ietf.org Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 00:49:49 -0000 Are you suggesting this due to people who are using the NAI in protocols other than RADIUS/Diameter? If you don't believe that there are a large number of people doing so, then I don't see the point of the split. Jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Alan DeKok > Sent: Saturday, December 15, 2012 9:17 AM > To: Jouni Korhonen > Cc: Benoit Claise; radext@ietf.org; radext-chairs@tools.ietf.org > Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; > The Network Access Identifier > > Jouni Korhonen wrote: > > Folks, > > > > As discussed in Atlanta, we are ready to ask for the WG adoption of draft- > dekok-radext-nai-02 (The Network Access Identifier "bis") starting today. > The plan is that once we have had the adoption call finished we can move the > document straight into WGLC (knowing there are already reviews done). > > > > The WG adoption call ends 20th Dec. This is a quick one week call since we > have had the document around quite long already. If you have concerns > against the document, raise them in the mailing list. Silence will be counted > as acceptance. Of course folks are encouraged to endorse the document in > the mailing list. > > As discusses early, the document should be split in two. > > My $0.02 is to accept the document as-is, rename it to draft-ietf-radext- > naibis-00.txt, and then split it. > > All of the RADIUS / Diameter text will then be removed, and placed into a > second document: draft-iet-radext-naiusage-00.txt > > The goal is to get the NAI-bis document published quickly. Then, discuss the > usage of NAI within RADIUS as a slightly longer-term project. > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From bclaise@cisco.com Thu Dec 20 08:17:32 2012 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 C41E221F896B for ; Thu, 20 Dec 2012 08:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.368 X-Spam-Level: X-Spam-Status: No, score=-10.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx1FbJOT7pYp for ; Thu, 20 Dec 2012 08:17:31 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D46A221F8972 for ; Thu, 20 Dec 2012 08:17:30 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBKGHOJ3007405; Thu, 20 Dec 2012 17:17:24 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBKGHMO0025002; Thu, 20 Dec 2012 17:17:24 +0100 (CET) Message-ID: <50D33A12.9040608@cisco.com> Date: Thu, 20 Dec 2012 17:17:22 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alan DeKok References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> <50CCB073.1090009@freeradius.org> In-Reply-To: <50CCB073.1090009@freeradius.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, "radext-chairs@tools.ietf.org" , Jouni Korhonen Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 20 Dec 2012 16:17:32 -0000 On 15/12/2012 18:16, Alan DeKok wrote: > Jouni Korhonen wrote: >> Folks, >> >> As discussed in Atlanta, we are ready to ask for the WG adoption of draft-dekok-radext-nai-02 (The Network Access Identifier "bis") starting today. The plan is that once we have had the adoption call finished we can move the document straight into WGLC (knowing there are already reviews done). >> >> The WG adoption call ends 20th Dec. This is a quick one week call since we have had the document around quite long already. If you have concerns against the document, raise them in the mailing list. Silence will be counted as acceptance. Of course folks are encouraged to endorse the document in the mailing list. > As discusses early, the document should be split in two. Have we discussed this at the last meeting? I don't recall. And the meeting minutes don't indicate this: http://www.ietf.org/proceedings/85/minutes/minutes-85-radext We just rechartered to include THIS document, and the next thing is that we need to split it??? Regards, Benoit > > My $0.02 is to accept the document as-is, rename it to > draft-ietf-radext-naibis-00.txt, and then split it. > > All of the RADIUS / Diameter text will then be removed, and placed > into a second document: draft-iet-radext-naiusage-00.txt > > The goal is to get the NAI-bis document published quickly. Then, > discuss the usage of NAI within RADIUS as a slightly longer-term project. > > Alan DeKok. > > From aland@deployingradius.com Thu Dec 20 09:01:21 2012 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 BA36521F893E for ; Thu, 20 Dec 2012 09:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj+vbNsnhtPC for ; Thu, 20 Dec 2012 09:01:20 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0E21F892D for ; Thu, 20 Dec 2012 09:01:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id AE7872241338; Thu, 20 Dec 2012 18:00:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1NA-kzkTPwl; Thu, 20 Dec 2012 18:00:11 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121028.dsl.bell.ca [70.26.46.196]) by power.freeradius.org (Postfix) with ESMTPSA id 084282241313; Thu, 20 Dec 2012 18:00:10 +0100 (CET) Message-ID: <50D34419.7090005@deployingradius.com> Date: Thu, 20 Dec 2012 12:00:09 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> <50CCB073.1090009@freeradius.org> <50D33A12.9040608@cisco.com> In-Reply-To: <50D33A12.9040608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 20 Dec 2012 17:01:21 -0000 Benoit Claise wrote: >> As discusses early, the document should be split in two. > Have we discussed this at the last meeting? I don't recall. I thought we had... > And the meeting minutes don't indicate this: > http://www.ietf.org/proceedings/85/minutes/minutes-85-radext > We just rechartered to include THIS document, and the next thing is that > we need to split it??? I'm OK with leaving it as one document. Alan DeKok. From jouni.nospam@gmail.com Sat Dec 22 02:01:40 2012 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 E15A921F8B32 for ; Sat, 22 Dec 2012 02:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pSj2MOb7oMX for ; Sat, 22 Dec 2012 02:01:40 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1D94921F8B2F for ; Sat, 22 Dec 2012 02:01:39 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id c4so2779144eek.22 for ; Sat, 22 Dec 2012 02:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=IinK4O/fgqCgclJKa2S2xvbC12Yt4/26JRhjcmAlAQY=; b=NkWjxnyR8qJ36o0pV7REJ/EgSjRlN/17JiQ2B09O6j972hgOAg/yTOfDJ3cJaOqDO5 j5AgZK/8+ulI6V+fiEmhXAo7kjIdrsOFaW8UkCdF+VB6ZJji57nJnXysR0wNFDO3eUuY sHPm2UIOg5f6EKI2Gu79nPRrKoHEWAaWvIo3IKfsAQFuasn28VJk22Gv764vf8ptL2xY 9ePDED25fi9VDXphAP1pw6dXlqtWW2KewzHrz2CnrmJImkkXvAppr5A3OiiVNy6YWFwY GkN9SVR9PmYe4uVI6rDtC07ur8icfP2BgtmTqHHT0ap1Y3rvDx2oVzltRsc5qdwugSJ5 W94A== X-Received: by 10.14.215.194 with SMTP id e42mr39488288eep.32.1356170498036; Sat, 22 Dec 2012 02:01:38 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:4c5b:41bf:145d:d7cc? ([2001:1bc8:101:f101:4c5b:41bf:145d:d7cc]) by mx.google.com with ESMTPS id 44sm27198085eek.0.2012.12.22.02.01.32 (version=SSLv3 cipher=OTHER); Sat, 22 Dec 2012 02:01:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <50D34419.7090005@deployingradius.com> Date: Sat, 22 Dec 2012 12:01:35 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4C9E0CE0-D42E-4E2B-8772-08DCDD276064@gmail.com> References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> <50CCB073.1090009@freeradius.org> <50D33A12.9040608@cisco.com> <50D34419.7090005@deployingradius.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1499) Cc: Benoit Claise , Alan DeKok Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 10:01:41 -0000 Folks, The deadline for the adoption call has completed. As there was no opposition to adopt the document, we will take it into WG process. @Alan: resubmit the current document as a draft-ietf-* as soon as possible. We will continue pursuing the one document approach (based on the current charter). Of course WG is now free to decide anything on the content as long as there is consensus and it fits to the charter. - Jouni & Mauricio > Folks, > > As discussed in Atlanta, we are ready to ask for the WG adoption > of draft-dekok-radext-nai-02 (The Network Access Identifier "bis") > starting today. The plan is that once we have had the adoption call > finished we can move the document straight into WGLC (knowing there > are already reviews done). > The WG adoption call ends 20th Dec. This is a quick one week call > since we have had the document around quite long already. If you > have concerns against the document, raise them in the mailing list. > Silence will be counted as acceptance. Of course folks are encouraged > to endorse the document in the mailing list. > > - Jouni & Mauricio On Dec 20, 2012, at 7:00 PM, Alan DeKok wrote: > Benoit Claise wrote: >>> As discusses early, the document should be split in two. >> Have we discussed this at the last meeting? I don't recall. > > I thought we had... > >> And the meeting minutes don't indicate this: >> http://www.ietf.org/proceedings/85/minutes/minutes-85-radext >> We just rechartered to include THIS document, and the next thing is that >> we need to split it??? > > I'm OK with leaving it as one document. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Sat Dec 22 05:24:31 2012 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 9F71D21F8ABC for ; Sat, 22 Dec 2012 05:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3vb4o2s9a2w for ; Sat, 22 Dec 2012 05:24:30 -0800 (PST) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by ietfa.amsl.com (Postfix) with ESMTP id F39FB21F8ABA for ; Sat, 22 Dec 2012 05:24:29 -0800 (PST) Received: from BLU002-W53 ([65.55.111.135]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Dec 2012 05:24:29 -0800 X-EIP: [AxNKBi7eUwangLpufxXAG7fFtzFDaczN] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1b2e9cc6-b081-478c-b1c1-eb0e27c94c30_" From: Bernard Aboba To: Jouni Korhonen , "radext@ietf.org" Date: Sat, 22 Dec 2012 05:24:29 -0800 Importance: Normal In-Reply-To: <4C9E0CE0-D42E-4E2B-8772-08DCDD276064@gmail.com> References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> <50CCB073.1090009@freeradius.org>,<50D33A12.9040608@cisco.com> <50D34419.7090005@deployingradius.com>, <4C9E0CE0-D42E-4E2B-8772-08DCDD276064@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2012 13:24:29.0592 (UTC) FILETIME=[ABF5B980:01CDE047] Cc: Benoit Claise , Alan DeKok Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 13:24:31 -0000 --_1b2e9cc6-b081-478c-b1c1-eb0e27c94c30_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > @Alan: resubmit the current document as a draft-ietf-* as soon as > possible. >=20 > We will continue pursuing the one document approach (based on the > current charter). Of course WG is now free to decide anything on > the content as long as there is consensus and it fits to the=20 > charter. [BA] When re-submitting the document as draft-ietf-*=2C please utilize the= pre-5378 boilerplate=2C since the document contains text from RFC 4282 and= RFC 2486. Also=2C some notes: Section 1.4 The motivation to revise [RFC4282] began with internationalization=0A= concerns raised in the context of [EDUROAM]. Section 2.1 of=0A= [RFC4282] defines ABNF for realms which limits the realm grammar to=0A= English letters=2C digits=2C and the hyphen "-" character. The intent= =0A= appears to have been to encode=2C compare=2C and transport realms with= =0A= the ToASCII operation defined in [RFC5890]. There are a number of=0A= problems with this approach: [BA] One big problem with the RFC 4282 ABNF=2C is that it is not aligned=20 with internationalization of the DNS. You might note this in the first bullet since it is referred to elsewhere.=20 Section 2.1 See [RFC5198] for a discussion of normalization=3B implementations of=0A= this specification MUST use the Normal Form Composed (NFC) for NAIs. [BA] I would recommend carrying over the text from RFC 5335: See [RFC5198] for a discussion of normalization=3B the use of=0A= normalization form NFC is RECOMMENDED. Section 2.3=20 Devices handling NAIs MUST support an NAI length of at least 72=0A= octets. Devices SHOULD support an NAI length of 253 octets.=0A= However=2C the following implementation issues should be considered: [BA] It should be pointed out that when using UTF-8 that the NAI octet length constraint may result in a more severe constraint on the number of UTF-8 characters. Section 2.4 Omitting the username part is RECOMMENDED over using a fixed username=0A= part=2C such as "anonymous"=2C since it provides an unambiguous way to= =0A= determine whether the username is intended to uniquely identify a=0A= single user. =20 [BA] I might consider changing (or deleting) this sentence=2C since in practice=2C I believe that use of a fixed username part is more popular than omitting the username part. =20 Section 2.5 o Realms MUST be of the form that can be registered as a=0A= Fully Qualified Domain Name (FQDN) within the DNS name system. [BA] Delete "name system".=20 Section 2.6=20 All normalization MUST be performed by end systems that take "local"=0A= text as input. That is=2C text that is in an encoding other than=0A= UTF-8=2C or that has locale-specific variations. In a network access=0A= setting=2C such systems are typically the client (e.g. EAP supplicant)= =0A= and the Authentication=2C Authorization=2C and Accounting (AAA) server.= =0A= [BA] As used in this section=2C "normalization" appears to go beyond the=20 conversion of Unicode characters to canonical form. I might rewrite this to say "Conversion to Unicode as well as normalization=20 is expected to be performed by end systems that take "local" text as input."=20 All other AAA systems (proxies=2C etc.) MUST NOT perform=0A= normalization. These other systems do not have access to locale and=0A= character set information that is available to end systems. [BA] Suggest rewriting to say "Since AAA proxies do not have access to=20 locale and character set information that is available to end systems=2C=20 they are typically incapable of converting local input to Unicode."=20 EAP supplicants MUST normalize user names that get placed in the EAP-=0A= Response/Identity field. They MUST NOT copy localized text into that=0A= field. This normalization SHOULD be performed once=2C and then cached= =0A= for subsequent use. [BA] Since RFC 4282 was published=2C RADIUS has been extended to cover appl= ication protocols such as in RFC 5090 (SIP and HTTP) and ABFAB. As a result=2C the advice needs to be g= eneralized.=20 Suggest rewriting to "Copying of localized text into fields that can subseq= uently be placed into the RADIUS User-Name attribute is problematic since this can result in a AA= A proxy encountering non-UTF8 characters within what it expects to be an NAI=2C resulting in potential di= fficulties in realm routing. =20 As an example=2C RFC 3579 Section 2.1 states: the NAS MUST copy the contents of the Type-Data field of the EAP-Respons= e/Identity received=0A= from the peer into the User-Name attribute As a result=2C AAA proxies expect the contents of the EAP-Response/Identity= sent by an EAP supplicant to consist of UTF-8 characters=2C not localized text." Section 2.9 The "realm" portion of the NAI is intended to be compatible with=0A= domain names used in DNS systems. However=2C the "realm" portion=0A= within AAA systems is intended to be a UTF-8 string=2C not an ASCII=0A= string as with the DNS protocol. Therefore=2C AAA systems transporting= =0A= NAIs in an AAA protocol MUST NOT encode the "utf8-realm" portion=0A= using the ToAscii function. That function creates strings that may=0A= be transported over DNS=2C and it is not appropriate for use within an= =0A= AAA protocol. [BA] Since the DNS protocol is 8-bit clean=2C I suggest the above text be m= odified as follows: =20 'The "realm" portion of the NAI is intended to be compatible with=0A= Internationalized Domain Names [RFC5890]. Since the "realm" portion=0A= as transported within the RADIUS User-Name attribute is composed of=20 U-labels=2C not A-labels=2C there is no reason for a NAS to apply the ToAscii function to the "realm" portion of an NAI prior to placing the NAI into a RADIUS User-Name attribute.' When the realm portion of the NAI is used as the basis for name=0A= lookups within the DNS system=2C the ToASCII operation defined in=0A= [RFC5890] MAY be used to convert internationalized realm names to=0A= ASCII. This function is normally handled by a DNS resolver library=0A= on the local system. When this function is not handled by a DNS=0A= resolver library=2C the AAA system MAY perform the ToAscii conversion=0A= itself=2C before passing the modified realm name to the DNS resolver=0A= library. [BA] As noted in RFC 6055=2C resolver APIs are not DNS-specific.=20 So I would use the term "resolver API" rather than DNS resolver library. Recommend the following text: When the realm portion of the NAI is used as the basis for name=0A= resolution=2C it may be necessary to convert internationalized realm names to ASCII using the ToASCII operation defined in=0A= [RFC5890]. As noted in [RFC6055] Section 2=2C resolver APIs are not nec= essarily DNS-specific=2C so that the ToASCII operation needs to be applied carefully: Applications that convert an IDN to A-label form before calling=0A= getaddrinfo() will result in name resolution failures if the Punycode= =0A= name is directly used in such protocols. Having libraries or=0A= protocols to convert from A-labels to the encoding scheme defined by= =0A= the protocol (e.g.=2C UTF-8) would require changes to APIs and/or=0A= servers=2C which IDNA was intended to avoid.=0A= =0A= As a result=2C applications that assume that non-ASCII names are=0A= resolved using the public DNS and blindly convert them to A-labels=0A= without knowledge of what protocol will be selected by the name=0A= resolution library=2C have problems. =20 Section 2.10.1 o Re-writing of the User-Name in AAA servers means that it may not=0A= match the EAP-Response/Identity fields. This mismatch may cause=0A= the home AAA server to reject the request as being malformed. [BA[ AAA servers should not be comparing the RADIUS User-Name attribute to the EAP-Response/Identity field=2C so I would suggest that this bullet be deleted. =20 = --_1b2e9cc6-b081-478c-b1c1-eb0e27c94c30_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B @Alan: resubmit = the current document as a draft-ietf-* as soon as
>=3B possible.
&g= t=3B
>=3B We will continue pursuing the one document approach (based = on the
>=3B current charter). Of course WG is now free to decide anyth= ing on
>=3B the content as long as there is consensus and it fits to t= he
>=3B charter.

[BA] =3B When re-submitting the document = as draft-ietf-*=2C please utilize the pre-5378 boilerplate=2C since the doc= ument contains text from RFC 4282 and RFC 2486.

Also=2C some notes:<= br>
Section 1.4
   The motivation to revise [RFC4282] began with=
 internationalization=0A=
   concerns raised in the context of [EDUROAM].  Section 2.1 of=0A=
   [RFC4282] defines ABNF for realms which limits the realm grammar to=0A=
   English letters=2C digits=2C and the hyphen "-" character.  The intent=
=0A=
   appears to have been to encode=2C compare=2C and transport realms with=
=0A=
   the ToASCII operation defined in [RFC5890].  There are a number of=0A=
   problems with this approach:

[BA] One bi=
g problem with the RFC 4282 ABNF=2C is that it is not aligned 
with inte=
rnationalization of the DNS.  You might note this in the first
bullet si=
nce it is referred to elsewhere. 

Section 2.1

   See [RFC5198=
] for a discussion of normalization=3B implementations of=0A=
   this specification MUST use the Normal Form Composed (NFC) for NAIs.
=

[BA] I would recommend carrying over the text from RFC 5335:

   =
See [RFC5198] for a discussion of normalization=3B the use of=0A=
   normalization form NFC is RECOMMENDED.

Section 2.3 

   Dev=
ices handling NAIs MUST support an NAI length of at least 72=0A=
   octets.  Devices SHOULD support an NAI length of 253 octets.=0A=
   However=2C the following implementation issues should be considered:
=

[BA] It should be pointed out that when using UTF-8 that the NAI
oct=
et length constraint may result in a more severe constraint on the
numbe=
r of UTF-8 characters.

Section 2.4

   Omitting the username p=
art is RECOMMENDED over using a fixed username=0A=
   part=2C such as "anonymous"=2C since it provides an unambiguous way to=
=0A=
   determine whether the username is intended to uniquely identify a=0A=
   single user. =3B 

[BA] I might consider changing (or deleting=
) this sentence=2C since in
practice=2C I believe that use of a fixed us=
ername part is more popular
than omitting the username part.  

Se=
ction 2.5

   o  Realms MUST be of the form that can be registered as=
 a=0A=
      Fully Qualified Domain Name (FQDN) within the DNS name system.
[BA] Delete "name system". 

Section 2.6 

   All normalizatio=
n MUST be performed by end systems that take "local"=0A=
   text as input.  That is=2C text that is in an encoding other than=0A=
   UTF-8=2C or that has locale-specific variations.  In a network access=0A=
   setting=2C such systems are typically the client (e.g. EAP supplicant)=
=0A=
   and the Authentication=2C Authorization=2C and Accounting (AAA) server.=
=0A=

[BA] As used in this section=2C "normalization" appears to go beyond th=
e 
conversion of Unicode characters to canonical form.  I might rewrite<=
br>this to say "Conversion to Unicode as well as normalization 
is expec=
ted to be performed by end systems that take "local" text
as input." 
   All other AAA systems (proxies=2C etc.)  MUST NOT perform=0A=
   normalization.  These other systems do not have access to locale and=0A=
   character set information that is available to end systems.

[BA] =
Suggest rewriting to say "Since AAA proxies do not have access to 
local=
e and character set information that is available to end systems=2C 
the=
y are typically incapable of converting local input to Unicode." 

  =
 EAP supplicants MUST normalize user names that get placed in the EAP-=0A=
   Response/Identity field.  They MUST NOT copy localized text into that=0A=
   field.  This normalization SHOULD be performed once=2C and then cached=
=0A=
   for subsequent use.

[BA] Since RFC 4282 was published=2C RADIUS h=
as been extended to cover application protocols such as in
RFC 5090 (SIP=
 and HTTP) and ABFAB.  As a result=2C the advice needs to be generalized. <=
br>
Suggest rewriting to "Copying of localized text into fields that can=
 subsequently be placed into
the RADIUS User-Name attribute is problemat=
ic since this can result in a AAA proxy encountering non-UTF8
characters=
 within what it expects to be an NAI=2C resulting in potential difficulties=
 in realm routing.  
As an example=2C RFC 3579 Section 2.1 states:
   the NAS MUST copy the contents of the Type-Data field of the EAP-Respo=
nse/Identity received=0A=
   from the peer into the User-Name attribute

As a result=2C AAA pro=
xies expect the contents of the EAP-Response/Identity sent by an EAP suppli=
cant to consist
of UTF-8 characters=2C not localized text."

Secti=
on 2.9

   The "realm" portion of the NAI is intended to be compatibl=
e with=0A=
   domain names used in DNS systems.  However=2C the "realm" portion=0A=
   within AAA systems is intended to be a UTF-8 string=2C not an ASCII=0A=
   string as with the DNS protocol.  Therefore=2C AAA systems transporting=
=0A=
   NAIs in an AAA protocol MUST NOT encode the "utf8-realm" portion=0A=
   using the ToAscii function.  That function creates strings that may=0A=
   be transported over DNS=2C and it is not appropriate for use within an=
=0A=
   AAA protocol.

[BA] Since the DNS protocol is 8-bit clean=2C I sug=
gest the above text be modified as follows:

 =3B
   'The "rea=
lm" portion of the NAI is intended to be compatible with=0A=
   Internationalized Domain Names [RFC5890]. Since the "realm" portion=0A=
   as transported within the RADIUS User-Name attribute is composed of 
=
   U-labels=2C not A-labels=2C there is no reason for a NAS to apply the   ToAscii function to the "realm" portion of an NAI prior to placing
 =
  the NAI into a RADIUS User-Name attribute.'





   Whe=
n the realm portion of the NAI is used as the basis for name=0A=
   lookups within the DNS system=2C the ToASCII operation defined in=0A=
   [RFC5890] MAY be used to convert internationalized realm names to=0A=
   ASCII.  This function is normally handled by a DNS resolver library=0A=
   on the local system.  When this function is not handled by a DNS=0A=
   resolver library=2C the AAA system MAY perform the ToAscii conversion=0A=
   itself=2C before passing the modified realm name to the DNS resolver=0A=
   library.

[BA] As noted in RFC 6055=2C resolver APIs are not DNS-s=
pecific. 
So I would use the term "resolver API" rather than DNS resolve=
r
library. Recommend the following text:


   When the realm po=
rtion of the NAI is used as the basis for name=0A=
   resolution=2C it may be necessary to convert internationalized
   rea=
lm names to ASCII using the ToASCII operation defined in=0A=
   [RFC5890].  As noted in [RFC6055] Section 2=2C resolver APIs are not nec=
essarily
   DNS-specific=2C so that the ToASCII operation needs to be ap=
plied
   carefully:

     Applications that convert an IDN to A-la=
bel form before calling=0A=
     getaddrinfo() will result in name resolution failures if the Punycode=
=0A=
     name is directly used in such protocols.  Having libraries or=0A=
     protocols to convert from A-labels to the encoding scheme defined by=
=0A=
     the protocol (e.g.=2C UTF-8) would require changes to APIs and/or=0A=
     servers=2C which IDNA was intended to avoid.=0A=
=0A=
     As a result=2C applications that assume that non-ASCII names are=0A=
     resolved using the public DNS and blindly convert them to A-labels=0A=
     without knowledge of what protocol will be selected by the name=0A=
     resolution library=2C have problems.  

Section 2.10.1

  =
 o  Re-writing of the User-Name in AAA servers means that it may not=0A=
      match the EAP-Response/Identity fields.  This mismatch may cause=0A=
       the home AAA server to reject the request as being malformed.
[BA[ AAA servers should not be comparing the RADIUS User-Name attributeto the EAP-Response/Identity field=2C so I would suggest that this bullet<=
br>be deleted.

 =3B


= --_1b2e9cc6-b081-478c-b1c1-eb0e27c94c30_-- From aland@deployingradius.com Sat Dec 22 05:30:27 2012 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 D07AC21F8929 for ; Sat, 22 Dec 2012 05:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHpaAu8153G6 for ; Sat, 22 Dec 2012 05:30:27 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D10321F84DD for ; Sat, 22 Dec 2012 05:30:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 00F332240903; Sat, 22 Dec 2012 14:30:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXvDMqHM6J9S; Sat, 22 Dec 2012 14:30:24 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 4397C224046D; Sat, 22 Dec 2012 14:30:24 +0100 (CET) Message-ID: <50D5B5EF.7080507@deployingradius.com> Date: Sat, 22 Dec 2012 08:30:23 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> <50CCB073.1090009@freeradius.org>, <50D33A12.9040608@cisco.com> <50D34419.7090005@deployingradius.com>, <4C9E0CE0-D42E-4E2B-8772-08DCDD276064@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benoit Claise , "radext@ietf.org" , Jouni Korhonen Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 13:30:27 -0000 Bernard Aboba wrote: > [BA] When re-submitting the document as draft-ietf-*, please utilize > the pre-5378 boilerplate, since the document contains text from RFC 4282 > and RFC 2486. OK. I'll address the rest of your comments in a -02 rev of the document. That makes change tracking easier. Alan DeKok. From aland@deployingradius.com Sat Dec 22 08:18:21 2012 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 7957621F8A57 for ; Sat, 22 Dec 2012 08:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EFNfSbTmcDb for ; Sat, 22 Dec 2012 08:18:21 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E297B21F8A52 for ; Sat, 22 Dec 2012 08:18:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 195042240903; Sat, 22 Dec 2012 17:17:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOywo6WqYNvb; Sat, 22 Dec 2012 17:17:25 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 9FEA0224046D; Sat, 22 Dec 2012 17:17:24 +0100 (CET) Message-ID: <50D5DD13.9020403@deployingradius.com> Date: Sat, 22 Dec 2012 11:17:23 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <0AA5F862-FC51-43E8-9099-2F3F15406164@gmail.com> <50CCB073.1090009@freeradius.org>, <50D33A12.9040608@cisco.com> <50D34419.7090005@deployingradius.com>, <4C9E0CE0-D42E-4E2B-8772-08DCDD276064@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benoit Claise , "radext@ietf.org" , Jouni Korhonen Subject: Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 16:18:21 -0000 Bernard Aboba wrote: > [BA] When re-submitting the document as draft-ietf-*, please utilize > the pre-5378 boilerplate, since the document contains text from RFC 4282 > and RFC 2486. > > Also, some notes: I've updated the draft as per your comments, with some minor edits. I'll upload the new version as soon as the -00 is approved. Unless there are pending concerns, we should probably do a last call on it in early January. Alan DeKok. From trac+radext@trac.tools.ietf.org Sat Dec 22 13:16:44 2012 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 C50EB21F8886 for ; Sat, 22 Dec 2012 13:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euyQy53LILUD for ; Sat, 22 Dec 2012 13:16:43 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCDF21F86C0 for ; Sat, 22 Dec 2012 13:16:43 -0800 (PST) Received: from localhost ([127.0.0.1]:38191 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TmWQw-0003pv-65; Sat, 22 Dec 2012 22:16:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 22 Dec 2012 21:16:38 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/143 Message-ID: <066.10a6da7d160ab2903db7bdb0822ee66d@trac.tools.ietf.org> X-Trac-Ticket-ID: 143 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: [radext] #143: Review of draft-dekok-radext-nai-02 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Dec 2012 21:16:44 -0000 #143: Review of draft-dekok-radext-nai-02 > @Alan: resubmit the current document as a draft-ietf-* as soon as > possible. > > We will continue pursuing the one document approach (based on the > current charter). Of course WG is now free to decide anything on > the content as long as there is consensus and it fits to the > charter. [BA] When re-submitting the document as draft-ietf-*, please utilize the pre-5378 boilerplate, since the document contains text from RFC 4282 and RFC 2486. Also, some notes: Section 1.4 The motivation to revise [RFC4282] began with internationalization concerns raised in the context of [EDUROAM]. Section 2.1 of [RFC4282] defines ABNF for realms which limits the realm grammar to English letters, digits, and the hyphen "-" character. The intent appears to have been to encode, compare, and transport realms with the ToASCII operation defined in [RFC5890]. There are a number of problems with this approach: [BA] One big problem with the RFC 4282 ABNF, is that it is not aligned with internationalization of the DNS. You might note this in the first bullet since it is referred to elsewhere. Section 2.1 See [RFC5198] for a discussion of normalization; implementations of this specification MUST use the Normal Form Composed (NFC) for NAIs. [BA] I would recommend carrying over the text from RFC 5335: See [RFC5198] for a discussion of normalization; the use of normalization form NFC is RECOMMENDED. Section 2.3 Devices handling NAIs MUST support an NAI length of at least 72 octets. Devices SHOULD support an NAI length of 253 octets. However, the following implementation issues should be considered: [BA] It should be pointed out that when using UTF-8 that the NAI octet length constraint may result in a more severe constraint on the number of UTF-8 characters. Section 2.4 Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since it provides an unambiguous way to determine whether the username is intended to uniquely identify a single user. [BA] I might consider changing (or deleting) this sentence, since in practice, I believe that use of a fixed username part is more popular than omitting the username part. Section 2.5 o Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS name system. [BA] Delete "name system". Section 2.6 All normalization MUST be performed by end systems that take "local" text as input. That is, text that is in an encoding other than UTF-8, or that has locale-specific variations. In a network access setting, such systems are typically the client (e.g. EAP supplicant) and the Authentication, Authorization, and Accounting (AAA) server. [BA] As used in this section, "normalization" appears to go beyond the conversion of Unicode characters to canonical form. I might rewrite this to say "Conversion to Unicode as well as normalization is expected to be performed by end systems that take "local" text as input." All other AAA systems (proxies, etc.) MUST NOT perform normalization. These other systems do not have access to locale and character set information that is available to end systems. [BA] Suggest rewriting to say "Since AAA proxies do not have access to locale and character set information that is available to end systems, they are typically incapable of converting local input to Unicode." EAP supplicants MUST normalize user names that get placed in the EAP- Response/Identity field. They MUST NOT copy localized text into that field. This normalization SHOULD be performed once, and then cached for subsequent use. [BA] Since RFC 4282 was published, RADIUS has been extended to cover application protocols such as in RFC 5090 (SIP and HTTP) and ABFAB. As a result, the advice needs to be generalized. Suggest rewriting to "Copying of localized text into fields that can subsequently be placed into the RADIUS User-Name attribute is problematic since this can result in a AAA proxy encountering non-UTF8 characters within what it expects to be an NAI, resulting in potential difficulties in realm routing. As an example, RFC 3579 Section 2.1 states: the NAS MUST copy the contents of the Type-Data field of the EAP- Response/Identity received from the peer into the User-Name attribute As a result, AAA proxies expect the contents of the EAP-Response/Identity sent by an EAP supplicant to consist of UTF-8 characters, not localized text." Section 2.9 The "realm" portion of the NAI is intended to be compatible with domain names used in DNS systems. However, the "realm" portion within AAA systems is intended to be a UTF-8 string, not an ASCII string as with the DNS protocol. Therefore, AAA systems transporting NAIs in an AAA protocol MUST NOT encode the "utf8-realm" portion using the ToAscii function. That function creates strings that may be transported over DNS, and it is not appropriate for use within an AAA protocol. [BA] Since the DNS protocol is 8-bit clean, I suggest the above text be modified as follows: 'The "realm" portion of the NAI is intended to be compatible with Internationalized Domain Names [RFC5890]. Since the "realm" portion as transported within the RADIUS User-Name attribute is composed of U-labels, not A-labels, there is no reason for a NAS to apply the ToAscii function to the "realm" portion of an NAI prior to placing the NAI into a RADIUS User-Name attribute.' When the realm portion of the NAI is used as the basis for name lookups within the DNS system, the ToASCII operation defined in [RFC5890] MAY be used to convert internationalized realm names to ASCII. This function is normally handled by a DNS resolver library on the local system. When this function is not handled by a DNS resolver library, the AAA system MAY perform the ToAscii conversion itself, before passing the modified realm name to the DNS resolver library. [BA] As noted in RFC 6055, resolver APIs are not DNS-specific. So I would use the term "resolver API" rather than DNS resolver library. Recommend the following text: When the realm portion of the NAI is used as the basis for name resolution, it may be necessary to convert internationalized realm names to ASCII using the ToASCII operation defined in [RFC5890]. As noted in [RFC6055] Section 2, resolver APIs are not necessarily DNS-specific, so that the ToASCII operation needs to be applied carefully: Applications that convert an IDN to A-label form before calling getaddrinfo() will result in name resolution failures if the Punycode name is directly used in such protocols. Having libraries or protocols to convert from A-labels to the encoding scheme defined by the protocol (e.g., UTF-8) would require changes to APIs and/or servers, which IDNA was intended to avoid. As a result, applications that assume that non-ASCII names are resolved using the public DNS and blindly convert them to A-labels without knowledge of what protocol will be selected by the name resolution library, have problems. Section 2.10.1 o Re-writing of the User-Name in AAA servers means that it may not match the EAP-Response/Identity fields. This mismatch may cause the home AAA server to reject the request as being malformed. [BA[ AAA servers should not be comparing the RADIUS User-Name attribute to the EAP-Response/Identity field, so I would suggest that this bullet be deleted. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: new Priority: major | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sat Dec 22 13:41:38 2012 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 9A43521F8B4B for ; Sat, 22 Dec 2012 13:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qtWs-XCnKUD for ; Sat, 22 Dec 2012 13:41:38 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F338D21F8B6A for ; Sat, 22 Dec 2012 13:41:37 -0800 (PST) Received: from localhost ([127.0.0.1]:39465 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TmWp4-0003nN-JD; Sat, 22 Dec 2012 22:41:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 22 Dec 2012 21:41:34 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/144 Message-ID: <066.415fcb8c259c89020f2bcba954e31bb7@trac.tools.ietf.org> X-Trac-Ticket-ID: 144 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: [radext] #144: Definition of NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Dec 2012 21:41:38 -0000 #144: Definition of NAI Since RFC 4282 was published, RADIUS has been extended to use in authentication and authorization of application layer protocols, such as in RFC 5090 (SIP and HTTP) and ABFAB. As a result, the definition of NAI in Section 1.1 needs to be re-examined: Network Access Identifier The Network Access Identifier (NAI) is the user identity submitted by the client during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's email address or the user identity submitted in an application layer authentication. Questions: 1. Should we continue to define the NAI as the user identity used by clients? While the network access clients (e.g. PPP, EAP, etc.) were 8-bit clean, protocols such as SIP, HTTP, etc. utilize escaping mechanisms. One potential alternative is to define the NAI as the contents of the RADIUS User-Name attribute. Note that this might imply some obligations on the part of a RADIUS client handling an application-layer protocol. 2. Should the abstract and Section 1 continue to refer solely to roaming and network access scenarios? 3. Should we continue to talk about "the NAI" as though there were a unique encoding for every protocol which might carry an NAI? Or should we be thinking about distinctions between "NAI-aware" applications such as PPP, RADIUS and EAP (which will obey the ABNF described in this document) and "NAI-unaware" applications (which may encode the NAI differently)? -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sat Dec 22 14:25:46 2012 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 D5C7621F8941 for ; Sat, 22 Dec 2012 14:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glGVEzRyUuU9 for ; Sat, 22 Dec 2012 14:25:46 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4924621F8929 for ; Sat, 22 Dec 2012 14:25:45 -0800 (PST) Received: from localhost ([127.0.0.1]:43139 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TmXVl-0005Fn-8J; Sat, 22 Dec 2012 23:25:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 22 Dec 2012 22:25:41 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/145 Message-ID: <066.dedf4d09031fe61f6c86516c36146705@trac.tools.ietf.org> X-Trac-Ticket-ID: 145 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: [radext] #145: Allowable code points X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Dec 2012 22:25:46 -0000 #145: Allowable code points As noted in http://tools.ietf.org/html/draft-iab-dns-zone-codepoint-pples, registration of U-labels using the entire range of Unicode code points probably should not be permitted: Abstract IDNA makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone. RFC 4282bis should probably contain a reference to this document, making it clear that just because a realm name is permitted by the ABNF does not mean it can be registered as an FQDN (as required by the IANA considerations section). -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: new Priority: major | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sat Dec 22 14:36:57 2012 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 8875021F8ABA for ; Sat, 22 Dec 2012 14:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r0GWhGbC+wB for ; Sat, 22 Dec 2012 14:36:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 48EBA21F89A4 for ; Sat, 22 Dec 2012 14:36:52 -0800 (PST) Received: from localhost ([127.0.0.1]:43636 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TmXgX-0000OH-1O; Sat, 22 Dec 2012 23:36:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 22 Dec 2012 22:36:49 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/146 Message-ID: <066.d7856f6a412e6225fc72caaacf5fd2b6@trac.tools.ietf.org> X-Trac-Ticket-ID: 146 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: [radext] #146: Terminology and RFC 6365 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 22 Dec 2012 22:36:57 -0000 #146: Terminology and RFC 6365 I would encourage this document to reference and use the terminology defined in RFC 6365. In particular, the terms "normalization", "canonicalization" and "locale" are defined there. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: new Priority: major | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sat Dec 22 16:42:40 2012 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 3698D21F8A53 for ; Sat, 22 Dec 2012 16:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbfoHVsnC5gK for ; Sat, 22 Dec 2012 16:42:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC3521F8A4D for ; Sat, 22 Dec 2012 16:42:39 -0800 (PST) Received: from localhost ([127.0.0.1]:52047 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TmZeC-0006zb-Cj; Sun, 23 Dec 2012 01:42:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 23 Dec 2012 00:42:32 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/147 Message-ID: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org> X-Trac-Ticket-ID: 147 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mikem@open.com.au, stefan.winter@restena.lu Resent-Message-Id: <20121223004239.7EC3521F8A4D@ietfa.amsl.com> Resent-Date: Sat, 22 Dec 2012 16:42:39 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Dec 2012 00:42:40 -0000 #147: Internationalization and draft-ietf-radext-dynamic-discovery Currently the internationalization advice provided in Section 2.3.1 appears to differ from that provided in RFC 4282bis, creating potentially unpredictable interactions. Dynamic server discovery as defined in this document is only applicable for AAA transactions where a RADIUS server receives a request with a realm for which no home RADIUS server is known. [BA] Does this paragraph really apply to RADIUS servers and not proxies? Typically a server will only check the realm and see if it represents a realm it is serving; if not an error is flagged. Asking RADIUS servers (not proxies) to route for realms for which they are not authoritative seems dangerous. Also, the meaning of "no home RADIUS server is known" is not clear. According to RFC 4282bis, only bit-by-bit comparisons are supported in the AAA infrastructure. As a result, were a client to not provide a normalized realm, the resulting failure of the comparison would trigger use of dynamic server discovery. Is this what is intended?? Section 2.3.1 Note well: The attribute User-Name is defined to contain UTF-8 text. In practice, the content may or may not be UTF-8. Even if UTF-8, it may or may not map to a domain name in the realm part. Implementors MUST take possible conversion error paths into consideration when parsing incoming User-Name attributes. [BA] This would appear to contradict RFC 4282bis requirements for realm normalization and realm correspondence to a legal FQDN. Although Section 2.2 does mention conversion to punycode, the exact steps to be performed are not described: It is expected that in most cases, the label used for the records is the DNS representation (punycode) of the literal realm name for which the server is the RADIUS server. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | dynamic-discovery@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Dec 23 05:08:46 2012 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 40CDC21F8473 for ; Sun, 23 Dec 2012 05:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.12 X-Spam-Level: X-Spam-Status: No, score=-102.12 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm6qZxhOcYDD for ; Sun, 23 Dec 2012 05:08:45 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5621F8470 for ; Sun, 23 Dec 2012 05:08:45 -0800 (PST) Received: from localhost ([127.0.0.1]:43691 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TmlII-0000Hy-5M; Sun, 23 Dec 2012 14:08:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Sun, 23 Dec 2012 13:08:42 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/143#comment:1 Message-ID: <081.de70ff20f0c68c320c2b29865a69a4f5@trac.tools.ietf.org> References: <066.10a6da7d160ab2903db7bdb0822ee66d@trac.tools.ietf.org> X-Trac-Ticket-ID: 143 In-Reply-To: <066.10a6da7d160ab2903db7bdb0822ee66d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #143: Review of draft-dekok-radext-nai-02 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 23 Dec 2012 13:08:46 -0000 #143: Review of draft-dekok-radext-nai-02 Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: Fixed in -01. Will be published as soon as it's approved. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | aland@deployingradius.com Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From aland@deployingradius.com Wed Dec 26 11:27:21 2012 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 6898721F8CCA for ; Wed, 26 Dec 2012 11:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heolXCjFSdjU for ; Wed, 26 Dec 2012 11:27:20 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C469521F8CB4 for ; Wed, 26 Dec 2012 11:27:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3F90A2240E7B; Wed, 26 Dec 2012 20:27:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsSyG2n1ZUtx; Wed, 26 Dec 2012 20:27:07 +0100 (CET) Received: from Thor-2.local (unknown [70.50.35.171]) by power.freeradius.org (Postfix) with ESMTPSA id 7F04C22404D1; Wed, 26 Dec 2012 20:27:06 +0100 (CET) Message-ID: <50DB4F89.5090909@deployingradius.com> Date: Wed, 26 Dec 2012 14:27:05 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <50C1CA9F.40100@cisco.com> <50C210F8.5060107@cisco.com> In-Reply-To: <50C210F8.5060107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , draft-ietf-radext-radius-extensions@tools.ietf.org Subject: Re: [radext] AD review: draft-ietf-radext-radius-extensions X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 26 Dec 2012 19:27:21 -0000 Benoit Claise wrote: > 1. > Section 2.1 > Length > > This field is identical to the Length field of the Attribute > format defined in [RFC2865] Section 5 . > > [RFC2865] Section 5 says: > Length > > The Length field is one octet, and indicates the length of this > Attribute _including _the Type, Length and Value fields. > > So the length doesn't include the one octet from Extended-Type, if I read the text correctly! > But I see "Permitted values are between _4_ and _255_." So it seems that the Extended-Type length is > included when I see 255. > Please improve the text. > Same remark for the other types. I've updated the intro text: The new attribute formats are designed to be compatible with the attribute format given in [RFC2865] Section 5. The meaning and interpretation of the Type and Length fields is unchanged from that specification. This reuse allows the new formats to be compatible RADIUS implementations which do not implement this specification. Those implementations can simply ignore the Value field of an attribute, or forward it verbatim. The changes to the attribute format come about by "stealing" one or more octets from the Value field. This change has the effect that the Value field of [RFC2865] Section 5 contains both the new octets given here, and any attribute-specific Value. The result is that Values in this specification are limited to less than 253 octets in size. This limitation is overcome through the use of the "Long Extended Type" format. We reiterate that the formats given in this document do not insert new data into an attribute. Instead, we "steal" one octet of Value, so that the definition of the Length field remains unchanged. and updated the text for the new formats: The Length field is one octet, and indicates the length of this Attribute including the Type, Length, Extended-Type, and Value fields. Permitted values are between 4 and 255. > 2. > What is the semantic of TLV Data type in section 2.3? > I mean: how do we define the relationship between sub-TLV? > Always logical AND? Or logical OR, or something else such as nested? RADIUS has always considered them to be a logical set, i.e. "and": If multiple TLVs with the same TLV-Type are present, the order of TLVs with the same TLV-Type MUST be preserved by any proxies. The order of TLVs of different TLV-Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of TLVs of different TLV-Types. A RADIUS server or client MUST NOT require TLVs of the same TLV-type to be contiguous. The interpretation of multiple TLVs of the same TLV-Type MUST be that of a logical "and", unless otherwise specified. That is, multiple TLVs are interpreted as specifying a set or a list of values. Specifications SHOULD NOT define TLVs to be interpreted as a logical "or". Doing so would mean that a RADIUS client or server would make an arbitrary, and non-deterministic choice among the values. > What is the impact for sub-TLV? It should be the same as RFC 2865 Section 5 comments in multiple attributes. I've copied && re-worded the text above. > Do you want to have a table like in RFC 2865 section 5.44 with the list > of attributes, explaining whether or not they can be part of the sub-TLV, and > with which multiplicity. Quite likely, yes. > 3. > Section 2.8 > When an implementation receives an "invalid attribute", it SHOULD be > silently discarded. If it is not discarded, it MUST NOT be handled > in the same manner as a well-formed attribute. > > Section 5.2 > Proxy servers SHOULD forward > attributes, even ones which they do not understand, or which are not > in a local dictionary. > > Question: what should proxy servers do with invalid attributes? Forwarded verbatim, I think. > Maybe, clarify "implementation" as it means client and server, and not proxy which should forward "invalid attribute" Proxies should forward them verbatim. For the simple reason that there is a *lot* of broken networking equipment. That equipment poaches on the IANA attribute space (1..255). So that equipment sends "invalid attributes". Maybe some other system in the network will understand them. > 1. > What's the max length of Long Extended Type? > > * defining a method which uses the additional octet to indicate data > fragmentation across multiple Attributes. This method provides a > standard way for an Attribute to carry more than 253 octets of > data. > > The max length is the one from the RADIUS packet, ie 4K, correct? Yes. > I propose to mention this. Suggested text: We note that the maximum size of a fragmented attribute is limited only by the RADIUS packet length limitation (i.e. 4096 octets, not counting various headers and overhead). Implementations SHOULD be able to handle fragmented attributes of 4096 octets. > I was wondering what's the link with this new entry in the charter: > Feb 2013 RADIUS packet fragmentation submitted as an Experimental RFC > Apparently, none. Not really, no. > > 2. In section 1.1, called "Unmet Requirements", why do you speak about: > It is RECOMMENDED that implementations support this specification. > It is RECOMMENDED that new specifications use the formats defined in > this specification. > > The alternative to the above recommendations is a circular argument > of not implementing this specification because no other standards > reference it, and also not defining new standards referencing this > specification because no implementations exist. > > Maybe a new section title for the 2 paragraphs above? OK. > 3. > For example, Livingston has Vendor-Id 307, and has defined an > attribute "IP-Pool" as number 6. This VSA can be uniquely identified > as 26.307.6. > > Don't you want to mention "Livingston-IP-Pool" instead? I refer to the attribute by it's historical name. > Similar remark for > For example, the company USR has been allocated Vendor-Id 429, and > has defined a "Version-Id" attribute as number 32768. This VSA can > be uniquely identified as 26.429.32768. Yes. > 4. > Section 2.7.1 > We RECOMMEND that vendors use their name as a unique prefix for > attribute names. > > Should RADIUS server implementations follow this rules when receiving attributes, > specifically when the same attribute name from different vendors is used. > So basically, enforcing global uniqueness of name, and an advice for the RADIUS server. The attribute names are local to the implementation. It's up to the implementation to enforce local name uniqueness. > 5. > * New specifications SHOULD NOT request allocation from the standard > Attribute Type Space (i.e. Attributes 1 through 255). That space > is deprecated. > > Deprecated: is it the right term? > Maybe you meant: Assignment from that space is not to be used. IANA can't do that. > In this case, this contradicts > * specifications which allocate a small number of attributes > (i.e. less than ten) should have all allocations made from > the standard space. I'll update that to change the allocation strategy to be a bit more flexible. > 6. > section 6.7 > * RADIUS proxy servers SHOULD forward all attributes, even ones > which they do not understand, or which are not in a local > dictionary. These attributes SHOULD be forwarded verbatim, with > no modifications or changes > Why do you repeat what you have written in section 5.2? Just to give checklists for people. > Proposal: ... > NEW: > * RADIUS proxy servers MUST follow the specifications in section 5.2 Sure. > > 8. > section 10.3.4 > * specifications which allocate a small number of attributes > (i.e. less than ten) should have all allocations made from > the standard space. > > * specifications which allocate a large number of attributes > (i.e. ten or more) should have all allocations made from the > extended space. > Instead of using a number, which would anyway not be relevant very long, why don't you have a relative number? > For example, instead of "i.e. ten or more", "compared to the remaining available number of entries in the standard space" OK. I'll just change it to "many" attributes. > 9. > Section 10.3.4 > * specifications which request allocation of an attribute > which can transport 253 or more octets of data should have > that attribute allocated from within the long extended space, > We note that Section 6.5 , above requires specifications to > request this allocation. > > > Are we ever going to face the issue that an attribute is right now below 253, but > there is a probability that it could be extended in the future? I doubt it. The attribute audit in the doc shows about 25 attributes out of ~5000 can be longer than 253 octets. So I'm not worried. > Do we want to advice that such an attribute be allocated to the long extended space right now? > Or do we advice to allocate a separate attribute in the future? If there's any chance it will be longer than 253 octets, it should be allocated as a "long" attribute. > > > _Editorial comments_ > 1. > Group the entry logically, like for the two entries related to "Extended Type" Sure. > 2. > Vendor-Id > > The 4 octets are the SMI Network Management Private Enterprise > Code of the Vendor in network byte order. > > Give a reference to http://www.iana.org/assignments/enterprise-numbers > Note: there are multiple instances of that sentence. OK. > 3. > Section 2.6 . Vendor-ID Field > > We define the Vendor-ID field of Vendor-Specific Attributes to > encompass the entire 4 octets of the Vendor field. [RFC2865 ] Section > 5.26 defined it to be 3 octets, with the high octet being zero. This > change has no immediate impact on RADIUS, as the maximum Private > Enterprise Code defined is still within 16 bits. > > There is something wrong with the reference: [RFC2865 ] Section 5.26 That seems to be an artifact of the text to HTML conversion on tools.ietf.org. > 4. ... > Section 2.7 ->Section 2.8 Fixed. > 5. > * Specifications of an ttribute which encodes 252 octets or less > => attribute Fixed. > > 6. > In section 1, please introduce with one sentence or two the guidelines in section 6. > Actually, it would also fit the abstract. > Reason: while I was reading through all these extra encodings, I had a lot questions that were answered in section 6. > I could have paid more attention to the table of content, sure but ... OK. > 7. > section 7 Rationale > Rationale for what? "Specifications rationale" maybe? Maybe "Rationale for this design" > 8. > section 10.3.4 > * specifications which request allocation of an Attribute of > data type TLV should have that attribute allocated from the > extended space. > Attribute -> attribute OK. > 9. > This document updates: 2865 , 2866 , 3575 , 5176 , 6158 > My guess is that those should be normative references Sure... it's an informational document, but OK. Alan DeKok. From internet-drafts@ietf.org Wed Dec 26 11:38:16 2012 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 6561C21F8CE6; Wed, 26 Dec 2012 11:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaJOqP0aI69a; Wed, 26 Dec 2012 11:38:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EB621F8CE9; Wed, 26 Dec 2012 11:38:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121226193815.18799.63894.idtracker@ietfa.amsl.com> Date: Wed, 26 Dec 2012 11:38:15 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 26 Dec 2012 19:38:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-07.txt Pages : 66 Date : 2012-12-26 Abstract: The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-extensions-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/