From owner-radiusext@ops.ietf.org Tue Sep 1 12:44:25 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F6E3A6BED for ; Tue, 1 Sep 2009 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.233 X-Spam-Level: * X-Spam-Status: No, score=1.233 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjEKBNEb3dGB for ; Tue, 1 Sep 2009 12:44:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9F383A6FC1 for ; Tue, 1 Sep 2009 12:42:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiZD4-000Pmb-Ng for radiusext-data0@psg.com; Tue, 01 Sep 2009 19:40:06 +0000 Received: from [65.55.116.18] (helo=blu0-omc1-s7.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiZD0-000Plx-V9 for radiusext@ops.ietf.org; Tue, 01 Sep 2009 19:40:04 +0000 Received: from BLU137-W25 ([65.55.116.7]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:40:02 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_73ada233-4a27-4935-9124-88c11b65da6e_" X-Originating-IP: [131.107.0.70] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Call for Agenda items for RADEXT Virtual Interim Meeting Date: Tue, 1 Sep 2009 12:40:02 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2009 19:40:02.0947 (UTC) FILETIME=[FFE0D530:01CA2B3B] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_73ada233-4a27-4935-9124-88c11b65da6e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a call for agenda items for the RADEXT Virtual Interim Meeting. If= you'd like to get on the agenda=2C please send email to David or myself.=20 --_73ada233-4a27-4935-9124-88c11b65da6e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a call for agenda items for the RADEXT Virtual Interim Meeting.&nbs= p=3B If you'd like to get on the agenda=2C please send email to David or my= self.


= --_73ada233-4a27-4935-9124-88c11b65da6e_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Sep 1 12:44:26 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F843A6BED for ; Tue, 1 Sep 2009 12:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.251 X-Spam-Level: * X-Spam-Status: No, score=1.251 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-+VHY6yjybe for ; Tue, 1 Sep 2009 12:44:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30ED53A6FA6 for ; Tue, 1 Sep 2009 12:42:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiZBD-000PM3-JI for radiusext-data0@psg.com; Tue, 01 Sep 2009 19:38:11 +0000 Received: from [65.55.116.15] (helo=blu0-omc1-s4.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MiZBA-000PKx-52 for radiusext@ops.ietf.org; Tue, 01 Sep 2009 19:38:09 +0000 Received: from BLU137-W32 ([65.55.116.8]) by blu0-omc1-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 12:38:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a642a527-345e-4fb0-803f-1bf85e389167_" X-Originating-IP: [131.107.0.70] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times Date: Tue, 1 Sep 2009 12:38:07 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2009 19:38:08.0182 (UTC) FILETIME=[BB791560:01CA2B3B] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_a642a527-345e-4fb0-803f-1bf85e389167_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be having a virtual interim meeting in early October. P= otential dates include: * Thursday=2C October 8 * Monday=2C October 12 * Tuesday=2C October 13 * Wednesday=2C October 14 To fill in your preferences for dates and times=2C please fill in the follo= wing Doodle poll: https://www.doodle.com/74uz2b233eu2vseg --_a642a527-345e-4fb0-803f-1bf85e389167_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be having a virtual interim meeting in early October.&nb= sp=3B Potential dates include:

* Thursday=2C October 8
* Monday= =2C October 12
* Tuesday=2C October 13
* Wednesday=2C October 14
<= br>To fill in your preferences for dates and times=2C please fill in the fo= llowing Doodle poll:
https://www.doodle.com/74uz2b233eu2vseg


=


= --_a642a527-345e-4fb0-803f-1bf85e389167_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 01:35:30 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CFB93A6E8C for ; Wed, 2 Sep 2009 01:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKvACjlNrL5y for ; Wed, 2 Sep 2009 01:35:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32E093A69AA for ; Wed, 2 Sep 2009 01:35:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MilGe-0008L4-BP for radiusext-data0@psg.com; Wed, 02 Sep 2009 08:32:36 +0000 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MilGZ-0008KS-Ds for radiusext@ops.ietf.org; Wed, 02 Sep 2009 08:32:33 +0000 X-IronPort-AV: E=Sophos;i="4.44,317,1249272000"; d="scan'208,217";a="172098496" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 02 Sep 2009 04:32:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Sep 2009 04:32:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2BA7.E15232AA" Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times Date: Wed, 2 Sep 2009 10:32:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times Thread-Index: AcorO/ZEQLW3TAonRBCfrBaqTmN9ywAa9Deg References: From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2BA7.E15232AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 What time zone?=20 =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, September 01, 2009 10:38 PM To: radiusext@ops.ietf.org Subject: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times =09 =09 The RADEXT WG will be having a virtual interim meeting in early October. Potential dates include: =09 * Thursday, October 8 * Monday, October 12 * Tuesday, October 13 * Wednesday, October 14 =09 To fill in your preferences for dates and times, please fill in the following Doodle poll: https://www.doodle.com/74uz2b233eu2vseg =09 =09 =09 =09 =09 =20 =09 ------_=_NextPart_001_01CA2BA7.E15232AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
What time=20 zone?
 
Dan
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Tuesday, September 01, 2009 10:38 = PM
To:=20 radiusext@ops.ietf.org
Subject: Action Requested: RADEXT WG = Virtual=20 Interim Meeting Dates, Times

The RADEXT WG will be having a virtual interim meeting in = early=20 October.  Potential dates include:

* Thursday, October = 8
*=20 Monday, October 12
* Tuesday, October 13
* Wednesday, October=20 14

To fill in your preferences for dates and times, please fill = in the=20 following Doodle=20 poll:
https://www.doodle.com/74uz2b233eu2vseg





<= /HTML> ------_=_NextPart_001_01CA2BA7.E15232AA-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 09:14:34 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2C23A6CB4 for ; Wed, 2 Sep 2009 09:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[AWL=-1.398, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxULq8XI7ym8 for ; Wed, 2 Sep 2009 09:14:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41FEA3A6B46 for ; Wed, 2 Sep 2009 09:14:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MisQ6-000OXi-As for radiusext-data0@psg.com; Wed, 02 Sep 2009 16:10:50 +0000 Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MisQ1-000OWB-1a for radiusext@ops.ietf.org; Wed, 02 Sep 2009 16:10:47 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA04.westchester.pa.mail.comcast.net with comcast id boJi1c0070EZKEL54sAiVx; Wed, 02 Sep 2009 16:10:42 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA01.westchester.pa.mail.comcast.net with comcast id bsAh1c0074H2mdz3MsAho4; Wed, 02 Sep 2009 16:10:42 +0000 From: "Dave Nelson" To: "'Bernard Aboba'" , References: Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times Date: Wed, 2 Sep 2009 12:10:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcorPCmiZCVDDjxFQfy2rGgaBQotZgAq5Ztg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > To fill in your preferences for dates and times, please fill > in the following Doodle poll: > https://www.doodle.com/74uz2b233eu2vseg What is the assumed time zone for the times listed at the top of the poll matrix? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 09:38:01 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1C428C137 for ; Wed, 2 Sep 2009 09:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.269 X-Spam-Level: * X-Spam-Status: No, score=1.269 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFuH-RXuDOWW for ; Wed, 2 Sep 2009 09:38:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3DF283A6358 for ; Wed, 2 Sep 2009 09:37:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mismt-0003rS-6e for radiusext-data0@psg.com; Wed, 02 Sep 2009 16:34:23 +0000 Received: from [65.55.111.166] (helo=blu0-omc4-s27.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mismo-0003qC-9v for radiusext@ops.ietf.org; Wed, 02 Sep 2009 16:34:20 +0000 Received: from BLU137-W5 ([65.55.111.135]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 09:34:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a221acec-455c-432f-8c29-bd90c10de88b_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times Date: Wed, 2 Sep 2009 09:34:18 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 02 Sep 2009 16:34:17.0782 (UTC) FILETIME=[37415D60:01CA2BEB] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_a221acec-455c-432f-8c29-bd90c10de88b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assumed time zone is PDT.=20 > From: d.b.nelson@comcast.net > To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org > Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates=2C= Times > Date: Wed=2C 2 Sep 2009 12:10:45 -0400 >=20 > > To fill in your preferences for dates and times=2C please fill > > in the following Doodle poll: > > https://www.doodle.com/74uz2b233eu2vseg >=20 > What is the assumed time zone for the times listed at the top of the poll > matrix? >=20 >=20 --_a221acec-455c-432f-8c29-bd90c10de88b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assumed time zone is PDT.

>=3B From: d.b.nelson@comcast.net
&g= t=3B To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org
>=3B Subj= ect: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates=2C Times=
>=3B Date: Wed=2C 2 Sep 2009 12:10:45 -0400
>=3B
>=3B >= =3B To fill in your preferences for dates and times=2C please fill
>= =3B >=3B in the following Doodle poll:
>=3B >=3B https://www.doodl= e.com/74uz2b233eu2vseg
>=3B
>=3B What is the assumed time zone f= or the times listed at the top of the poll
>=3B matrix?
>=3B
= >=3B
= --_a221acec-455c-432f-8c29-bd90c10de88b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 14:42:52 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F0B3A7148 for ; Wed, 2 Sep 2009 14:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfa7IUTj-Krr for ; Wed, 2 Sep 2009 14:42:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 517633A6A6D for ; Wed, 2 Sep 2009 14:42:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MixW2-000INs-76 for radiusext-data0@psg.com; Wed, 02 Sep 2009 21:37:18 +0000 Received: from [216.40.44.67] (helo=smtprelay.hostedemail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MixVx-000IMr-Mb for radiusext@ops.ietf.org; Wed, 02 Sep 2009 21:37:15 +0000 Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id 1CD7B83C3F6 for ; Wed, 2 Sep 2009 21:37:12 +0000 (UTC) X-Session-Marker: 6461766964406D6974746F6E2E636F6D X-Filterd-Recvd-Size: 1472 Received: from webmail05 (imap-ext [216.40.42.5]) (Authenticated sender: david@mitton.com) by omf05.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Sep 2009 21:37:11 +0000 (UTC) Received: from 128.221.197.56 ([128.221.197.56]) by webmail05 (Tucows Webmail) with HTTP; Wed, 2 Sep 2009 21:37:11 +0000 (GMT) Date: Wed, 2 Sep 2009 21:37:11 +0000 (GMT) From: David Mitton Reply-To: david@mitton.com To: radiusext@ops.ietf.org Message-ID: <1908411328.100621.1251927431963.JavaMail.mail@webmail05> Subject: Re: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.221.197.56] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Thanks, I had the same question. and FYI: Oct 12th is Columbus Day, or according to my calendar, Thanksgiving Day in Canada. Dave. Sep 2, 2009 12:38:30 PM, owner-radiusext@ops.ietf.org wrote: Assumed time zone is PDT. > From: d.b.nelson@comcast.net > To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org > Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times > Date: Wed, 2 Sep 2009 12:10:45 -0400 > > > To fill in your preferences for dates and times, please fill > > in the following Doodle poll: > > https://www.doodle.com/74uz2b233eu2vseg > > What is the assumed time zone for the times listed at the top of the poll > matrix? > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 15:57:34 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEDE3A6C23 for ; Wed, 2 Sep 2009 15:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.978 X-Spam-Level: * X-Spam-Status: No, score=1.978 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb2GJlwAl00l for ; Wed, 2 Sep 2009 15:57:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85E2128C563 for ; Wed, 2 Sep 2009 15:57:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Miyi0-000Ass-J2 for radiusext-data0@psg.com; Wed, 02 Sep 2009 22:53:44 +0000 Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Miyhv-000As1-DA for radiusext@ops.ietf.org; Wed, 02 Sep 2009 22:53:41 +0000 Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id bvlu1c0050b6N64A2ytgRM; Wed, 02 Sep 2009 22:53:40 +0000 Received: from gwzPC ([71.35.51.12]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id bytT1c00W0FnazK8PytWzl; Wed, 02 Sep 2009 22:53:37 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: References: In-Reply-To: Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times Date: Wed, 2 Sep 2009 15:53:26 -0700 Message-ID: <017f01ca2c20$345ee3d0$9d1cab70$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0180_01CA2BE5.88000BD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcorPDkhni+GKZxOQM2j7K4ZXIaStQA49fog Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0180_01CA2BE5.88000BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The RADEXT WG will be having a virtual interim meeting in early October. Why? Potential dates include: * Thursday, October 8 * Monday, October 12 * Tuesday, October 13 * Wednesday, October 14 To fill in your preferences for dates and times, please fill in the following Doodle poll: https://www.doodle.com/74uz2b233eu2vseg ------=_NextPart_000_0180_01CA2BE5.88000BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RADEXT WG will be having a = virtual interim meeting in early October. 

Why?

Potential dates include:

* Thursday, October 8
* Monday, October 12
* Tuesday, October 13
* Wednesday, October 14

To fill in your preferences for dates and times, please fill in the = following Doodle poll:
https://www.doodle.com/74uz2b233eu2vseg



 

------=_NextPart_000_0180_01CA2BE5.88000BD0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 16:46:06 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9869328C104 for ; Wed, 2 Sep 2009 16:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5EjQ+k2D6V4 for ; Wed, 2 Sep 2009 16:46:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 885183A69DA for ; Wed, 2 Sep 2009 16:46:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MizS1-000LO5-K4 for radiusext-data0@psg.com; Wed, 02 Sep 2009 23:41:17 +0000 Received: from [65.55.116.34] (helo=blu0-omc1-s23.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MizRn-000LGg-CJ for radiusext@ops.ietf.org; Wed, 02 Sep 2009 23:41:05 +0000 Received: from BLU137-W1 ([65.55.116.8]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 16:40:59 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8907f3f2-4237-48ff-a215-48719ee1fd80_" X-Originating-IP: [97.113.1.218] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Issue 311: IESG DISCUSS comments Date: Wed, 2 Sep 2009 16:40:58 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 02 Sep 2009 23:40:59.0147 (UTC) FILETIME=[D2DBA5B0:01CA2C26] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_8907f3f2-4237-48ff-a215-48719ee1fd80_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboardIssue 311: IESG DISCUSS comments Submitter name: Jari Arkko =20 Submitter email address: jari.arkko@piuha.net=20 Date first submitted: May 7=2C 2009 Reference: https://datatracker.ietf.org/idtracker/ballot/2883/ Document:=20 Design-Guidelines=20 Comment type: Technical=20 Priority: S =20 Section: Various Rationale/Explanation of issue: Jari Arkko: Discuss [2009-05-07]: Great doc! I will vote Yes on it=2C but I wanted to discuss two issues first=2C one is a Discuss-level problem and the other one a Comment that I'd like you to consider. The first issue is that Section 2.3 suggests 16-bit vendor space attribute number fields to replace the existing 8-bit recommendation. There are a couple of problems with this. First=2C if you really mean to change the recommendation=2C then Updates: RFC 2865 header in the beginning of the document would have been appropriate. Secondly=2C while I agree with the advice of going for 16 bits=2C the document is silent on some of the issues involved in such a change=2C such as: - Does RADIUS dictionary software support the VSA format for 16 bits=2C 8 bits=2C or both? - How do you cleanly print or report VSAs when you do not know if the field size is 8 or 16 bits? I realize that this situation already exists since the format was never required to be followed=2C but your new recommendation makes a potential problem much more likely to appear. Previously=2C you could print something like Vendor =3D ACME= =2C Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that. - Can a vendor who moved from 8 bits to 16 bits deal with this? Comment [2009-05-07]: I do agree that for functionality FOO=2C both the functionality itself and the MIB=2C RADIUS=2C etc. work should take place in the same standards body. However=2C Section 3.1 could have said a couple of additional things as well: The issues of attribute space and choice of forum are distinct=3B there is no reason why IETF couldn't use its own vendor code=2C for instance. The section also does not mention one of the potential drawbacks of SDO-driven development model: it is easy to come up with a number of different solutions to the same generic problem=2C as opposed to finding a common solution. Ralph Droms: Comment [2009-04-20]: Trivial: does the "text" data type include a trailing '\0' byte? I ask bec= ause there has been confusion about this point in DHCP options and it might be g= ood to make the convention explicit. Lars Eggert: Comment [2009-04-20]: Section 2.1.1=2C paragraph 2: > The Length field in the RADIUS packet header is defined in [RFC2865] > Section 3. It is noted there that the maximum length of a RADIUS > packet is 4096 octets. As a result=2C attribute designers SHOULD NOT > assume that a RADIUS implementation can successfully process RADIUS > packets larger than 4096 octets. You may want to point out that even with messages less than 4096 but larger than the PMTU=2C persistent IP fragmentation will be incurred=2C which makes communication much more brittle=2C and might even want to suggest that therefore RADIUS messages should be kept as small as possible. See RFC5405 Section 3.2. Adrian Farrel: Comment [2009-04-18]: Trivial=2C but... Section 2.1.1 says that some address data types are in "network byte order" while others are "most significant octet first". Is there a rea= son for this difference? I wonder if the text in seciton 4 should be stronger. You have... This document does not require that the IANA update any existing registry or create any new registry=2C but includes information that affects the IANA=2C for example: * includes guidelines that recommend against allocation from the RADIUS standard attribute space in other SDO RADIUS Attribute specifications. But=2C in fact=2C IANA are bound by the registry rules already laid down an= d cannot make allocations except following IETF process as defined by RFC 3575. Russ Housley: Comment [2009-04-20]: The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some editorial suggestions. ID nits complains that reference [8] appears in Appendix B.6 but not in the References. The Introduction Section should be a non-normative section. However=2C Section 1.1 uses normative statements (RECOMMENDED and NOT RECOMMENDED) before those terms are defined in Section 1.3. The acronym AAA should be expanded. When referring to the appendixes=2C I think the draft should talk about appendixes=2C not about sections. For example=2C it should talk about Appendix A.5=2C not about Section A.5. Alexey Melnikov: Comment [2009-04-21]: This is a fine document. Some minor comments: 3.3. RADIUS Operational Model The RADIUS operational model includes several assumptions: * The RADIUS protocol is stateless=3B * Provisioning of services is not possible within an Access-Reject=3B * Distinction between authorization checks and user authentication=3B * Authentication and integrity protection of RADIUS packets=3B * The RADIUS protocol is a Request/Response protocol. * Packet length restriction. Half of this list is comprised from full sentences=2C the other half is not= . I would appreciate if you can make this consistent=2C otherwise it is difficult to read/understand. Tim Polk: Comment [2009-05-06]: It might be valuable to supplement the current security considerations sect= ion with a discussion of issues that arise if SDOs do not follow the guidelines presented here. For example=2C relying on MTU discovery to support transpor= ting large amounts of data could fail and result in denial of service=2C lost accounting data=2C etc... Robert Sparks: Comment [2009-04-22]: "the above procedure" in 3.1.1 (page 17) could be hard to follow for some readers. Recommend providing a more explicit pointer. Proposed Resolution: Discuss EMAILING FOR THE GREATER GOOD Join me= --_8907f3f2-4237-48ff-a215-48719ee1fd80_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboard= Issue 311: IESG DISCUSS comments
Submitter name: Jari Arkko =3B
Submitter email address: jari.arkko@piuha.net
Date first submitted:  =3B May 7=2C 2009
Reference: https://datatracker.ietf.org/idtracker/ballot/2883/
Document:=20 Design-Guidelines=20
Comment type: Technical
Priority: S =3B
Section: =3BVarious
Rationale/Explanation of issue:
Jari Arkko:

Discuss [2009-05-07]:
Great doc! I will vote Yes on it=2C but I wanted to discuss two issues
first=2C one is a Discuss-level problem and the other one a Comment that
I'd like you to consider.
The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.

There are a couple of problems with this. First=2C if you really mean
to change the recommendation=2C then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.

Secondly=2C while I agree with the advice of going for 16 bits=2C the
document is silent on some of the issues involved in such a change=2C
such as:

- Does RADIUS dictionary software support the VSA format for 16 bits=2C 8
  bits=2C or both?

- How do you cleanly print or report VSAs when you do not know if the
  field size is 8 or 16 bits? I realize that this situation already
  exists since the format was never required to be followed=2C but
  your new recommendation makes a potential problem much more likely
  to appear. Previously=2C you could print something like Vendor =3D ACME=
=2C
  Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that.

- Can a vendor who moved from 8 bits to 16 bits deal with this?

Comment [2009-05-07]:
I do agree that for functionality FOO=2C both the functionality itself
and the MIB=2C RADIUS=2C etc. work should take place in the same standards
body. However=2C Section 3.1 could have said a couple of additional things
as well:

The issues of attribute space and choice of forum are distinct=3B there
is no reason why IETF couldn't use its own vendor code=2C for instance.

The section also does not mention one of the potential drawbacks of
SDO-driven development model: it is easy to come up with a number of
different solutions to the same generic problem=2C as opposed to finding
a common solution.

Ralph Droms:

Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte?  I ask bec=
ause
there has been confusion about this point in DHCP options and it might be g=
ood
to make the convention explicit.

Lars Eggert:

Comment [2009-04-20]:

Section 2.1.1=2C paragraph 2:
>=3B    The Length field in the RADIUS packet header is defined in [RFC28=
65]
>=3B    Section 3.  It is noted there that the maximum length of a RADIUS
>=3B    packet is 4096 octets.  As a result=2C attribute designers SHOULD=
 NOT
>=3B    assume that a RADIUS implementation can successfully process RADI=
US
>=3B    packets larger than 4096 octets.

  You may want to point out that even with messages less than 4096 but
  larger than the PMTU=2C persistent IP fragmentation will be incurred=2C
  which makes communication much more brittle=2C and might even want to
  suggest that therefore RADIUS messages should be kept as small as
  possible. See RFC5405 Section 3.2.

Adrian Farrel:

Comment [2009-04-18]:
Trivial=2C but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a rea=
son
for this difference?

I wonder if the text in seciton 4 should be stronger. You have...

   This document does not require that the IANA update any existing
   registry or create any new registry=2C but includes information that
   affects the IANA=2C for example:

      * includes guidelines that recommend against allocation from the
        RADIUS standard attribute space in other SDO RADIUS Attribute
        specifications.

But=2C in fact=2C IANA are bound by the registry rules already laid down an=
d cannot
make allocations except following IETF process as defined by RFC 3575.

Russ Housley:

Comment [2009-04-20]:

  The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
  editorial suggestions.

  ID nits complains that reference [8] appears in Appendix B.6 but not
  in the References.

  The Introduction Section should be a non-normative section. However=2C
  Section 1.1 uses normative statements (RECOMMENDED and NOT
  RECOMMENDED) before those terms are defined in Section 1.3.

  The acronym AAA should be expanded.

  When referring to the appendixes=2C I think the draft should talk about
  appendixes=2C not about sections. For example=2C it should talk about
  Appendix A.5=2C not about Section A.5.

Alexey Melnikov:

Comment [2009-04-21]:
This is a fine document. Some minor comments:

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless=3B
      * Provisioning of services is not possible within an
        Access-Reject=3B
      * Distinction between authorization checks and user
        authentication=3B
      * Authentication and integrity protection of RADIUS packets=3B
      * The RADIUS protocol is a Request/Response protocol.
      * Packet length restriction.

Half of this list is comprised from full sentences=2C the other half is not=
. I
would appreciate if you can make this consistent=2C otherwise it
is difficult to read/understand.

Tim Polk:

Comment [2009-05-06]:
It might be valuable to supplement the current security considerations sect=
ion
with a discussion of issues that arise if SDOs do not follow the guidelines
presented here. For example=2C relying on MTU discovery to support transpor=
ting
large amounts of data could fail and result in denial of service=2C lost
accounting data=2C etc...

Robert Sparks:

Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.
Proposed Resolution: Discuss

= --_8907f3f2-4237-48ff-a215-48719ee1fd80_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 16:55:02 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46303A67FD for ; Wed, 2 Sep 2009 16:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.276 X-Spam-Level: * X-Spam-Status: No, score=1.276 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAWo2kGKsNsS for ; Wed, 2 Sep 2009 16:55:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 471CE3A63EC for ; Wed, 2 Sep 2009 16:55:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MizcG-000NZi-9A for radiusext-data0@psg.com; Wed, 02 Sep 2009 23:51:52 +0000 Received: from [65.55.116.30] (helo=blu0-omc1-s19.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mizc9-000NYf-SK for radiusext@ops.ietf.org; Wed, 02 Sep 2009 23:51:50 +0000 Received: from BLU137-W31 ([65.55.116.9]) by blu0-omc1-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 16:51:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_73b09e04-e9be-410b-b709-1f5ee1f52453_" X-Originating-IP: [97.113.1.218] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Issue 312: Normative Reference to Extended Attributes Document Date: Wed, 2 Sep 2009 16:51:45 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 02 Sep 2009 23:51:45.0438 (UTC) FILETIME=[5413D3E0:01CA2C28] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_73b09e04-e9be-410b-b709-1f5ee1f52453_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboardIssue 312: Normative Reference to Extended Attributes Documen= t Submitter name: Bernard Aboba =20 Submitter email address: bernard_aboba@hotmail.com=20 Date first submitted: July 31=2C 2009 =20 Reference:=20 Document:=20 Design-Guidelines=20 Comment type: Editorial=20 Priority: S =20 Section: 2.2=2C 3=2C 6.1 =20 Rationale/Explanation of issue: In Section 2.2 and 3 the Design Guidelines document contains normative=20 language relating to the Extended Attributes document. This has resulted=20 in a normative dependency on that document. Given that the Extended=20 Attributes document is not yet completed=2C and can contain its own usage=20 guidelines=2C is the normative reference appropriate?=20 2.2. Extended RADIUS Attributes The extended RADIUS attribute document [EXTEN]=20 defines a number of extensions to RADIUS. The standard attribute space is=20 extended by permitting standard allocations from within a specific subset o= f the=20 VSA space=3B the format of extended attributes is defined=3B and extended d= ata types=20 are defined within that format. New specifications seeking to extend the=20 standard RADIUS data model SHOULD examine [EXTEN]=20 to see if their needs fit within the extended RADIUS data model.From Sectio= n=20 3:=20 Recent extensions to the RADIUS data model such as [EXTEN] make it possible to minimize the use of complex attributes. New specifications seeking to extend the standard RADIUS data model SHOULD examine [EXTEN] to see if their needs fit within the extended RADIUS data model. Proposed Resolution: Discuss EMAILING FOR THE GREATER GOOD Join me= --_73b09e04-e9be-410b-b709-1f5ee1f52453_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboard= Issue 312: Normative Reference to Extended Attributes Docum= ent
Submitter name: Bernard Aboba =3B
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: July 31=2C 2009 =3B
Reference: =3B
Document:=20 Design-Guidelines=20
Comment type: Editorial
Priority: S =3B
Section: =3B2.2=2C 3=2C 6.1 =3B
Rationale/Explanation of issue:
In Section 2.2 and 3 the Design Guidelines document contains normative=20 language relating to the Extended Attributes document. =3B This has res= ulted=20 in a normative dependency on that document. =3B Given that the Extended= =20 Attributes document is not yet completed=2C and can contain its own usage=20 guidelines=2C is the normative reference appropriate?

2.2. Extended RADIUS Attributes

The extended RADIUS attribute document [EXT= EN]=20 defines a number of extensions to RADIUS. The standard attribute space is=20 extended by permitting standard allocations from within a specific subset o= f the=20 VSA space=3B the format of extended attributes is defined=3B and extended d= ata types=20 are defined within that format. New specifications seeking to extend the=20 standard RADIUS data model SHOULD examine [EXTEN= ]=20 to see if their needs fit within the extended RADIUS data model.From Sectio= n=20 3: 
   Recent extensions to the RADIUS data model such a=
s [EXTEN] make it
   possible to minimize the use of complex attributes.  New
   specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their need=
s fit within the extended
   RADIUS data model.
Proposed Resolution: Discuss






= 3D"i'm" EMAILING FOR THE GREATER GOOD
Join me
=
3D"i'm" EMAILING FOR THE GREAT= ER GOOD
Join me
= --_73b09e04-e9be-410b-b709-1f5ee1f52453_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Sep 2 17:00:29 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1896228C11E for ; Wed, 2 Sep 2009 17:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.088 X-Spam-Level: ** X-Spam-Status: No, score=2.088 tagged_above=-999 required=5 tests=[AWL=-1.610, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fVGf048reFf for ; Wed, 2 Sep 2009 17:00:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A79AC3A63EC for ; Wed, 2 Sep 2009 17:00:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mizhy-000Ovo-Tj for radiusext-data0@psg.com; Wed, 02 Sep 2009 23:57:46 +0000 Received: from [65.55.116.18] (helo=blu0-omc1-s7.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mizhu-000OvS-Sz for radiusext@ops.ietf.org; Wed, 02 Sep 2009 23:57:44 +0000 Received: from BLU137-W31 ([65.55.116.9]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 16:57:42 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_" X-Originating-IP: [97.113.1.218] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Issue 313: Security Exemption Date: Wed, 2 Sep 2009 16:57:42 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 02 Sep 2009 23:57:42.0900 (UTC) FILETIME=[29243340:01CA2C29] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboardIssue 313: Security Exemption Submitter name: Alan DeKok =20 Submitter email address: aland@deployingradius.com Date first submitted: July 24=2C 2009 =20 Reference: http://ops.ietf.org/lists/radiusext/2009/msg00340.html Document:=20 Design Guidelines Comment type: Technical=20 Priority: S =20 Section: A.2.1 Rationale/Explanation of issue: Section A.2.1 states: * Complex data structures defined only within RADIUS. The additional functionality defined in [EXTEN] SHOULD be used instead. This recommendation does not apply to new attributes for authentication or security=2C as described below in Section A.2.2. Should this exemption be removed and/or clarified? d.b.nelson@comcast.net wrote: > Yeah. I've always been a bit uncomfortable with the "security > functionality" escape clause in the RADIUS Design Guidelines draft.=20 > Lots of things can reasonably be claimed to be "security related". I > would have preferred the exception to be crafted a bit narrower=2C just > for this reason. But=2C unless wording of Design Guidelines is changed= =2C > you have a legitimate argument. I believe the intent was "related to RADIUS security". The guidelines document could be updated to address this. RADIUS could transport parameters for *another* protocol. Those attributes are not security related. They either follow the RADIUS data model (int=2C IP address=2C etc.)=2C or they are "opaque data" that RADIUS = is simply transporting on the behalf of the other protocol. Proposed Resolution: Discuss EMAILING FOR THE GREATER GOOD Join me= --_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboard= Issue 313: Security Exemption
Submitter name: Alan DeKok =3B
Submitter email address: =3B aland@deployingradius.com
Date first submitted: July 24=2C 2009 =3B
Reference: http://ops.ietf.org/lists/radiusext/2009/msg00340.html
Document:=20 Design Guidelines
Comment type: Technical
Priority: S =3B
Section: =3B =3BA.2.1
Rationale/Explanation of issue:
Section A.2.1 states:
      * Complex data structures defined only within =
RADIUS.
        The additional functionality defined in [E=
XTEN] SHOULD be used
        instead.  This recommendation does not apply to new attributes
        for authentication or security=2C as described below in Section
        A.2.2.
Should this exemption be removed and/or clarified?

d.b.nelson@comcast.net wrote:
>=3B Yeah.  I've always been a bit uncomfortable with the "security
>=3B functionality" escape clause in the RADIUS Design Guidelines draft.=
=20
>=3B Lots of things can reasonably be claimed to be "security related".  =
I
>=3B would have preferred the exception to be crafted a bit narrower=2C j=
ust
>=3B for this reason.  But=2C unless wording of Design Guidelines is chan=
ged=2C
>=3B you have a legitimate argument.

  I believe the intent was "related to RADIUS security".  The guidelines
document could be updated to address this.

  RADIUS could transport parameters for *another* protocol.  Those
attributes are not security related.  They either follow the RADIUS data
model (int=2C IP address=2C etc.)=2C or they are "opaque data" that RADIUS =
is
simply transporting on the behalf of the other protocol.

Proposed Resolution: Discuss






3D"i'm" EMAILING FOR THE GREATER G=
OOD
Join me

=

--_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  2 17:20:44 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB133A6C9C for ; Wed,  2 Sep 2009 17:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.322
X-Spam-Level: *
X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZLQOmpid7RE for ; Wed,  2 Sep 2009 17:20:43 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D1063A6B1A for ; Wed,  2 Sep 2009 17:20:43 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mj01t-0003cu-RX for radiusext-data0@psg.com; Thu, 03 Sep 2009 00:18:21 +0000
Received: from [65.55.116.48] (helo=blu0-omc1-s37.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mj01o-0003c5-Ok for radiusext@ops.ietf.org; Thu, 03 Sep 2009 00:18:18 +0000
Received: from BLU137-W28 ([65.55.116.9]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 17:18:16 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_"
X-Originating-IP: [97.113.1.218]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
Date: Wed, 2 Sep 2009 17:18:15 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Sep 2009 00:18:16.0238 (UTC) FILETIME=[0844A4E0:01CA2C2C]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a reminder of the ongoing call for review of the document "DTLS as =
a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item.  This document is
being targeted at Experimental
status.=20

=20
The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-dtls

The original call for review expired August 7=2C 2009=2C but no comments we=
re received.  This call for input will last until October 2=2C 2009.  Pleas=
e send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.  If you have comments on the
document=2C please also send these to the list in the format described on
the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/


--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






This is a reminder of the ongoing call for review of the document "DTLS as =
a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item. =3B This document is
being targeted at Experimental
status. 

 =3B
The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-dtls
The original call for review expired August 7=2C 2009=2C but no commen=
ts were received. =3B This call for input will last until October 2=2C =
2009. =3B Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item. =3B If you have comments on the
document=2C please also send these to the list in the format described on
the RADEXT WG Issues list:
http://ww=
w.drizzle.com/~aboba/RADEXT/


=

--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  2 17:29:32 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C923A68CC for ; Wed,  2 Sep 2009 17:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.337
X-Spam-Level: *
X-Spam-Status: No, score=1.337 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsekCtx3dCaU for ; Wed,  2 Sep 2009 17:29:31 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 758973A688C for ; Wed,  2 Sep 2009 17:29:31 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mj0AH-0005Q9-T3 for radiusext-data0@psg.com; Thu, 03 Sep 2009 00:27:01 +0000
Received: from [65.55.116.37] (helo=blu0-omc1-s26.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mj0AD-0005PR-38 for radiusext@ops.ietf.org; Thu, 03 Sep 2009 00:26:59 +0000
Received: from BLU137-W14 ([65.55.116.7]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 17:26:56 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_b155f041-0060-4939-8440-679293bec851_"
X-Originating-IP: [97.113.1.218]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"
Date: Wed, 2 Sep 2009 17:26:57 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Sep 2009 00:26:56.0596 (UTC) FILETIME=[3E6CF940:01CA2C2D]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_b155f041-0060-4939-8440-679293bec851_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a reminder of an ongoing RADEXT WG last call on "RADIUS over TCP"=
=2C prior to sending this document on to the IESG for
publication as an Experimental RFC.  The document is available for
inspection here:

http://tools.ietf.org/html/draft-ietf-radext-tcp-transport



The original RADEXT
WG last call lasted until August 7=2C 2009=2C but no comments were received=
.  We will therefore extend the comment period until October 2=2C 2009. Ple=
ase send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list: http://www.drizzle.com/~aboba/RADEXT/




--_b155f041-0060-4939-8440-679293bec851_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






This is a reminder of an ongoing RADEXT WG last call on "RADIUS over TCP"=
=2C prior to sending this document on to the IESG for
publication as an Experimental RFC. =3B The document is available for
inspection here:

http://tools.ietf.org/html/draft-ietf-radext-tcp-transport



The original RADEXT
WG last call lasted until August 7=2C 2009=2C but no comments were received=
. =3B We will therefore extend the comment period until October 2=2C 20=
09. Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list: http://www.drizzle.com/~aboba/RADEXT/




=

--_b155f041-0060-4939-8440-679293bec851_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  2 17:32:14 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CFA3A68CC for ; Wed,  2 Sep 2009 17:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.98
X-Spam-Level: 
X-Spam-Status: No, score=0.98 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0i9ZKowMiOz for ; Wed,  2 Sep 2009 17:32:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 323E13A688C for ; Wed,  2 Sep 2009 17:32:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mj0Di-0006CL-6S for radiusext-data0@psg.com; Thu, 03 Sep 2009 00:30:34 +0000
Received: from [65.55.116.43] (helo=blu0-omc1-s32.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mj0Db-0006B6-S2 for radiusext@ops.ietf.org; Thu, 03 Sep 2009 00:30:30 +0000
Received: from BLU137-W17 ([65.55.116.8]) by blu0-omc1-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 17:30:27 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_"
X-Originating-IP: [97.113.1.218]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Issue 314:  My Problem
Date: Wed, 2 Sep 2009 17:30:27 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Sep 2009 00:30:27.0543 (UTC) FILETIME=[BC28EE70:01CA2C2D]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue 314: My Problem

Submitter name: Hannes Tschofenig =20

Submitter email address: Hannes.Tschofenig@gmx.net

Date first submitted:  May 9=2C 2009

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html

Document:=20
Design-Guidelines=20


Comment type: Technical=20

Priority: S =20

Section: Various =20

Rationale/Explanation of issue:
The document assumes a certain implementation and processing model. This
model is not explicitly documented in the draft and unfortunately has
implications on the design of attributes particularly when it comes to data
types used by RADIUS attributes and for the claimed problems that arise fro=
m
adding new code to the RADIUS server.=20

In previous mail exchanges on the list I did not agree with certain aspects
of the implicitly assumed progressing model. I am=2C however=2C OK with
documenting the model and to thereby make it explicit to the reader. The
understanding of some of the claimed limitations might also be clearer.
PS: FYI=2C I stated my concerns previously on the RADEXT list.

[Alan DeKok] Do you have suggested text for the document?
[Hannes]=20
I can compile some text but this is not saying that I agree with the assume=
d
model=2C i.e. one where essentially no improvement in implementations was m=
ade
over the last 10 years.=20
[David Nelson]=20
Perhaps=2C but this seems to presume that data-dictionary-driven server
implementations are a liability which requires improvement.  Like a network
management application for SNMP which has the ability to "enroll" a MIB
module without code changes=2C a RADIUS server that can simply add new
attributes to its dictionary is a boon to users.

We can split hairs about what types of user-added executable scripts are or
are not "coding".  I still think that the data dictionary architecture is a
very powerful concept.  Not to mention a very widely deployed one.


--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Issue 314: My Problem

Submitter name: Hannes Tschofenig =3B 

Submitter email address: Hannes.Tschofenig@gmx.net

Date first submitted: =3B May 9=2C 2009

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html

Document:=20
Design-Guidelines=20


Comment type: Technical 

Priority: S =3B 

Section: =3BVarious =3B 

Rationale/Explanation of issue:

The document assumes a certain implementation and processing model. Th=
is
model is not explicitly documented in the draft and unfortunately has=

implications on the design of attributes particularly when it comes to =
data
types used by RADIUS attributes and for the claimed problems that a=
rise from
adding new code to the RADIUS server. 

In previous mail=
 exchanges on the list I did not agree with certain aspects
of the impli=
citly assumed progressing model. I am=2C however=2C OK with
documenting =
the model and to thereby make it explicit to the reader. The
understandi=
ng of some of the claimed limitations might also be clearer.


PS: FYI=2C I stated my concerns previously on the RADEXT list.


[Alan DeKok] Do you have suggested text for the document?


[Hannes] 


I can compile some text but this is not saying that I agree with the a=
ssumed
model=2C i.e. one where essentially no improvement in implementat=
ions was made
over the last 10 years. 


[David Nelson] 


Perhaps=2C but this seems to presume that data-dictionary-driven serve=
r
implementations are a liability which requires improvement.  Like a ne=
twork
management application for SNMP which has the ability to "enroll" =
a MIB
module without code changes=2C a RADIUS server that can simply add=
 new
attributes to its dictionary is a boon to users.

We can spli=
t hairs about what types of user-added executable scripts are or
are not=
 "coding".  I still think that the data dictionary architecture is a
ver=
y powerful concept.  Not to mention a very widely deployed one.


=

--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep  3 06:20:06 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FB928C1A4 for ; Thu,  3 Sep 2009 06:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.223
X-Spam-Level: 
X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myf-E5jE5Ro0 for ; Thu,  3 Sep 2009 06:20:06 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3A5228C16D for ; Thu,  3 Sep 2009 06:20:05 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjC9w-000CRp-Ir for radiusext-data0@psg.com; Thu, 03 Sep 2009 13:15:28 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjC9v-000CRC-VS for radiusext@ops.ietf.org; Thu, 03 Sep 2009 13:15:28 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 667B2123445D; Thu,  3 Sep 2009 15:15:24 +0200 (CEST)
Message-ID: <4A9FC16C.9020600@deployingradius.com>
Date: Thu, 03 Sep 2009 15:15:24 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 314:  My Problem
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

> The document assumes a certain implementation and processing model.

  Maybe the document isn't clear.  It assumes a certain *data* model for
RADIUS.  It assumes that maintaining that data model is a good idea.  It
explicitly states that a *typical* RADIUS server uses a data dictionary:

  Section 2.1.3 says:

   ... RADIUS server implementations
   typically provide support for basic data types, and define attributes
   in a data dictionary.  ...

  Maybe this should be "MANY RADIUS server implementations..."

  Or "RADIUS server implementations have traditionally provided support..."

> This
> model is not explicitly documented in the draft and unfortunately has
> implications on the design of attributes particularly when it comes to data
> types used by RADIUS attributes and for the claimed problems that arise from
> adding new code to the RADIUS server.  

  Even if an implementation can easily handle complex attributes defined
in a "dictionary", is there any *reason* to use complex attributes where
the standard data types would be sufficient?

  If not, then the existing text would seem to be sufficient.

> In previous mail exchanges on the list I did not agree with certain aspects
> of the implicitly assumed progressing model. I am, however, OK with
> documenting the model and to thereby make it explicit to the reader. The
> understanding of some of the claimed limitations might also be clearer.

  The draft explicitly mentions a *typical* data model implemented by a
RADIUS server.

  As for making the limitations clear, the document already does that.
It states that the data dictionary approach means that it allows:

   ... RADIUS servers to be configured to support new attributes
   without requiring server code changes.  ...

  Should we add some text here saying:

  "Some implementations can support more complex attributes defined in a
more complex dictionary than is traditional.  However, this document
does not recommend defining complex attributes for all of the reasons
outlined in Section 2.1.3"

  I fail to see how that will help.

  The text allows more complex implementations of dictionaries.  Nothing
in the text *forbids* more complex implementations of dictionaries.
Nothing in the text suggests that it is a good idea to use complex types
where standard types would suffice.  The document already discusses the
typical model, along with its limitations.

  So... why do we need to say any more?

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep  3 06:25:35 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B8428C15D for ; Thu,  3 Sep 2009 06:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.171
X-Spam-Level: 
X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV-mtH4564Uz for ; Thu,  3 Sep 2009 06:25:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B389328C0FD for ; Thu,  3 Sep 2009 06:25:34 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjCHl-0000Zf-Km for radiusext-data0@psg.com; Thu, 03 Sep 2009 13:23:33 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjCHl-0000YP-1c for radiusext@ops.ietf.org; Thu, 03 Sep 2009 13:23:33 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 1CC8F123445D; Thu,  3 Sep 2009 15:23:32 +0200 (CEST)
Message-ID: <4A9FC353.3050104@deployingradius.com>
Date: Thu, 03 Sep 2009 15:23:31 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 313:  Security Exemption
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

>   RADIUS could transport parameters for *another* protocol.  Those
> attributes are not security related.  They either follow the RADIUS data
> model (int, IP address, etc.), or they are "opaque data" that RADIUS is
> simply transporting on the behalf of the other protocol.

  Suggested text in Section A.2.2.:

A.2.2. Complex Data Types

   Does the attribute:

   * define a complex data type
   * that the RADIUS server and/or client will not treat as opaque data
     (see Section A.1.3)
   * for purposes other than authentication or security?

   If the answers to all of the above items are "yes", this data type
   SHOULD be replaced
   with simpler types, as discussed above in Section A.2.1.  Also see
   Section 2.1.3 for a discussion of why complex types are problematic.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep  3 06:30:39 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61B223A6C7F for ; Thu,  3 Sep 2009 06:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.126
X-Spam-Level: 
X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4FozJmb5ngr for ; Thu,  3 Sep 2009 06:30:38 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 633513A69A7 for ; Thu,  3 Sep 2009 06:30:38 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjCM0-0007qx-Ig for radiusext-data0@psg.com; Thu, 03 Sep 2009 13:27:56 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjCLz-0007oC-VQ for radiusext@ops.ietf.org; Thu, 03 Sep 2009 13:27:56 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 0D742123445D; Thu,  3 Sep 2009 15:27:55 +0200 (CEST)
Message-ID: <4A9FC45A.7090702@deployingradius.com>
Date: Thu, 03 Sep 2009 15:27:54 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> In Section 2.2 and 3 the Design Guidelines document contains normative
> language relating to the Extended Attributes document.  This has
> resulted in a normative dependency on that document.  Given that the
> Extended Attributes document is not yet completed, and can contain its
> own usage guidelines, is the normative reference appropriate?

  No.  The reference should be informative.

  I think it would be OK to simply move the [EXTEN] document from the
"normative" to "informative" section of the references.  Nothing in the
design guideline documents depends on [EXTEN], so there's no reason to
have a normative dependency.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep  3 09:38:34 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264B23A6838 for ; Thu,  3 Sep 2009 09:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.087
X-Spam-Level: 
X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTBdxYHDHdz4 for ; Thu,  3 Sep 2009 09:38:32 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE2B73A6C67 for ; Thu,  3 Sep 2009 09:37:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjEJH-0006uE-6E for radiusext-data0@psg.com; Thu, 03 Sep 2009 15:33:15 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjEDa-0005b8-Bw for radiusext@ops.ietf.org; Thu, 03 Sep 2009 15:31:22 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id E719C123445D; Thu,  3 Sep 2009 17:27:20 +0200 (CEST)
Message-ID: <4A9FE058.3050500@deployingradius.com>
Date: Thu, 03 Sep 2009 17:27:20 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 311: IESG DISCUSS comments
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

> The first issue is that Section 2.3 suggests 16-bit vendor space
> attribute number fields to replace the existing 8-bit recommendation.
> 
> There are a couple of problems with this. First, if you really mean
> to change the recommendation, then Updates: RFC 2865 header in the
> beginning of the document would have been appropriate.

  Can a BCP update a standards track document?

> Secondly, while I agree with the advice of going for 16 bits, the
> document is silent on some of the issues involved in such a change,
> such as:
> 
> - Does RADIUS dictionary software support the VSA format for 16 bits, 8
>   bits, or both?

  Most common RADIUS implementations support both.

> - How do you cleanly print or report VSAs when you do not know if the
>   field size is 8 or 16 bits? I realize that this situation already
>   exists since the format was never required to be followed, but
>   your new recommendation makes a potential problem much more likely
>   to appear. Previously, you could print something like Vendor = ACME,
>   Code = 17, Contents = ABCDEF0011... Now you couldn't do that.

  The key is that VSAs depend on a Vendor-Id.  See below.

> - Can a vendor who moved from 8 bits to 16 bits deal with this?

  Suggested text to resolve this issue:

Although [RFC2865] does not mandate it, implementations commonly
assume that the Vendor Id can be used as a key to determine the
on-the-wire format of a VSA.  Vendors therefore SHOULD NOT use
multiple formats for VSAs that are associated with a particular Vendor
Id.  A vendor wishing to use multiple VSA formats, SHOULD request one
Vendor Id for each VSA format that they will use.

> Comment [2009-05-07]:
> I do agree that for functionality FOO, both the functionality itself
> and the MIB, RADIUS, etc. work should take place in the same standards
> body. However, Section 3.1 could have said a couple of additional things
> as well:
> 
> The issues of attribute space and choice of forum are distinct; there
> is no reason why IETF couldn't use its own vendor code, for instance.

  Yes.  I don't see a need to mention that in this document.

> The section also does not mention one of the potential drawbacks of
> SDO-driven development model: it is easy to come up with a number of
> different solutions to the same generic problem, as opposed to finding
> a common solution.

  Section 3.1.3 says:

   Any new RADIUS attributes or values intended for interoperable use
   across a broad spectrum of the Internet Community SHOULD follow the
   normal IETF process, and SHOULD result in allocations from the RADIUS
   standard space.

> Ralph Droms:
> 
> Comment [2009-04-20]:
> Trivial: does the "text" data type include a trailing '\0' byte?  I ask because
> there has been confusion about this point in DHCP options and it might be good
> to make the convention explicit.

 RFC 2865 Section 5 already states explicitly that trailing '\0' bytes
are not to be used.

> Lars Eggert:
> 
> Comment [2009-04-20]:
> 
> Section 2.1.1, paragraph 2:
>>    The Length field in the RADIUS packet header is defined in [RFC2865]
>>    Section 3.  It is noted there that the maximum length of a RADIUS
>>    packet is 4096 octets.  As a result, attribute designers SHOULD NOT
>>    assume that a RADIUS implementation can successfully process RADIUS
>>    packets larger than 4096 octets.
> 
>   You may want to point out that even with messages less than 4096 but
>   larger than the PMTU, persistent IP fragmentation will be incurred,
>   which makes communication much more brittle, and might even want to
>   suggest that therefore RADIUS messages should be kept as small as
>   possible. See RFC5405 Section 3.2.

  Suggested text in 2.1.1:

Even when packets are less than 4096 octets, they may be larger than
the Path Maximum Transmission Unit (PMTU).  Any packet larger than the
PMTU will be fragmented, making communications more brittle.
Transport of fragmented UDP packets appears to be a poorly tested code
path on network devices.  Some devices appear to be incapable of
transporting fragmented UDP packets, making it difficult to deploy
RADIUS in a network where those devices are deployed.  We RECOMMEND
that RADIUS messages be kept as small possible.


> Adrian Farrel:
> 
> Comment [2009-04-18]:
> Trivial, but...
> Section 2.1.1 says that some address data types are in "network
> byte order" while others are "most significant octet first". Is there a reason
> for this difference?

  Tradition.  I suggest changing all references to use "in network byte
order".

> I wonder if the text in seciton 4 should be stronger. You have...
> 
>    This document does not require that the IANA update any existing
>    registry or create any new registry, but includes information that
>    affects the IANA, for example:
> 
>       * includes guidelines that recommend against allocation from the
>         RADIUS standard attribute space in other SDO RADIUS Attribute
>         specifications.
> 
> But, in fact, IANA are bound by the registry rules already laid down and cannot
> make allocations except following IETF process as defined by RFC 3575.

  I think that's what the above text says.  Maybe the text could say:

	... recommend against SELF allocation ...

  The idea is to tell the SDOs that it's a bad idea to avoid IANA.

> Russ Housley:
> 
> Comment [2009-04-20]:
> 
>   The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
>   editorial suggestions.
> 
>   ID nits complains that reference [8] appears in Appendix B.6 but not
>   in the References.

  It's a quote from another document.

>   The Introduction Section should be a non-normative section. However,
>   Section 1.1 uses normative statements (RECOMMENDED and NOT
>   RECOMMENDED) before those terms are defined in Section 1.3.

  The simplest thing to do is to move Section 1.1 to be after the
current Section 1.3.

>   The acronym AAA should be expanded.

  OK, fixed.

>   When referring to the appendixes, I think the draft should talk about
>   appendixes, not about sections. For example, it should talk about
>   Appendix A.5, not about Section A.5.

  OK, fixed.

> Alexey Melnikov:
> 
> Comment [2009-04-21]:
> This is a fine document. Some minor comments:
> 
> 3.3.  RADIUS Operational Model
> 
>    The RADIUS operational model includes several assumptions:
> 
>       * The RADIUS protocol is stateless;
>       * Provisioning of services is not possible within an
>         Access-Reject;
>       * Distinction between authorization checks and user
>         authentication;
>       * Authentication and integrity protection of RADIUS packets;
>       * The RADIUS protocol is a Request/Response protocol.
>       * Packet length restriction.
> 
> Half of this list is comprised from full sentences, the other half is not. I
> would appreciate if you can make this consistent, otherwise it
> is difficult to read/understand.

  I suggest the following re-write:

* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
  Access-Reject;
* There is a distinction between authorization checks and user
  authentication;
* The protocol provices for authentication and integrity
  protection of packets;
* The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions.

> Tim Polk:
> 
> Comment [2009-05-06]:
> It might be valuable to supplement the current security considerations section
> with a discussion of issues that arise if SDOs do not follow the guidelines
> presented here. For example, relying on MTU discovery to support transporting
> large amounts of data could fail and result in denial of service, lost
> accounting data, etc...

  Suggested text:

Implementations not following the suggestions outlined in this
document may be subject to a problems such as ambiguous protocol
decoding, packet loss leading to loss of billing information, and
denial of service attacks.

> Robert Sparks:
> 
> Comment [2009-04-22]:
> "the above procedure" in 3.1.1 (page 17) could be hard to follow for some
> readers. Recommend providing a more explicit pointer.

  It should say "IETF process" instead of "the above procedure".

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Fri Sep  4 01:17:47 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F363A691E for ; Fri,  4 Sep 2009 01:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.052
X-Spam-Level: 
X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vGnV3urUFuI for ; Fri,  4 Sep 2009 01:17:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB56C3A683F for ; Fri,  4 Sep 2009 01:17:43 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjTvJ-000DpW-Dd for radiusext-data0@psg.com; Fri, 04 Sep 2009 08:13:33 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjTux-000Do4-5M for radiusext@ops.ietf.org; Fri, 04 Sep 2009 08:13:24 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 186D2123445D; Fri,  4 Sep 2009 10:13:09 +0200 (CEST)
Message-ID: <4AA0CC13.3010906@deployingradius.com>
Date: Fri, 04 Sep 2009 10:13:07 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 311: IESG DISCUSS comments
References:  <4A9FE058.3050500@deployingradius.com> 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> You might also mention that firewalls and other filtering devices often
> discard fragments.

  OK.

> Jari is correct that allocation requests will be handled according to
> RFC 3575,
> but as part of the Expert Review process, Design Guidelines will
> presumably be
> consulted.  So while self-allocation is certainly not a good practice,
> the whole
> point of IANA allocation is to enable consistent allocation.  Perhaps
> the text
> can be clear that the recommendations are relevant to Expert Reviewers
> appointed under the IANA considerations of RFC 3575, not for IANA itself.

  OK.  I suggest adding a first bullet about this point to the IANA
considerations section:

...
This document does not require that the IANA update any existing
registry or create any new registry, but includes information that
affects the IANA, which:

* includes specific guidelines for Expert Reviewers appointed
  under the IANA considerations of [RFC3575]
* includes guidelines that recommend against self allocation from
  ...

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Fri Sep  4 01:24:26 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F7E3A67F1 for ; Fri,  4 Sep 2009 01:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.021
X-Spam-Level: 
X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+I9SWKN-N8d for ; Fri,  4 Sep 2009 01:24:25 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 618D03A67B4 for ; Fri,  4 Sep 2009 01:24:25 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjU2u-000F59-3o for radiusext-data0@psg.com; Fri, 04 Sep 2009 08:21:24 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjU2Z-000F3Y-5y for radiusext@ops.ietf.org; Fri, 04 Sep 2009 08:21:16 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 28084123445D; Fri,  4 Sep 2009 10:21:02 +0200 (CEST)
Message-ID: <4AA0CDEE.8040109@deployingradius.com>
Date: Fri, 04 Sep 2009 10:21:02 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document
References:  <4A9FC45A.7090702@deployingradius.com> 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> The reason why we ended up with a normative reference was because there
> were normative statements preceeding the reference.  So I don't think it's
> enough just to change the reference to informative; you'll also need to
> change
> the text.

  I think it's simplest to simply remove all references to the extended
attributes document.  We can then mark it as updating the design
guidelines document, to permit the extended attribute format.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Fri Sep  4 10:57:22 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCAC13A683D for ; Fri,  4 Sep 2009 10:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.972
X-Spam-Level: 
X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgBOgBFdT1La for ; Fri,  4 Sep 2009 10:57:22 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 009943A6358 for ; Fri,  4 Sep 2009 10:57:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mjc1r-000MEX-JO for radiusext-data0@psg.com; Fri, 04 Sep 2009 16:52:51 +0000
Received: from [65.55.111.93] (helo=blu0-omc2-s18.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjbxD-000L5r-8P for radiusext@ops.ietf.org; Fri, 04 Sep 2009 16:48:03 +0000
Received: from BLU137-W8 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 09:48:02 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 311: IESG DISCUSS comments
Date: Fri, 4 Sep 2009 09:48:03 -0700
Importance: Normal
In-Reply-To: <4AA0CC13.3010906@deployingradius.com>
References:  <4A9FE058.3050500@deployingradius.com>  <4AA0CC13.3010906@deployingradius.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Sep 2009 16:48:02.0538 (UTC) FILETIME=[77ACA4A0:01CA2D7F]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


looks good.


> Date: Fri=2C 4 Sep 2009 10:13:07 +0200
> From: aland@deployingradius.com
> To: bernard_aboba@hotmail.com
> CC: radiusext@ops.ietf.org
> Subject: Re: Issue 311: IESG DISCUSS comments
>=20
> Bernard Aboba wrote:
> > You might also mention that firewalls and other filtering devices often
> > discard fragments.
>=20
>   OK.
>=20
> > Jari is correct that allocation requests will be handled according to
> > RFC 3575=2C
> > but as part of the Expert Review process=2C Design Guidelines will
> > presumably be
> > consulted.  So while self-allocation is certainly not a good practice=
=2C
> > the whole
> > point of IANA allocation is to enable consistent allocation.  Perhaps
> > the text
> > can be clear that the recommendations are relevant to Expert Reviewers
> > appointed under the IANA considerations of RFC 3575=2C not for IANA its=
elf.
>=20
>   OK.  I suggest adding a first bullet about this point to the IANA
> considerations section:
>=20
> ...
> This document does not require that the IANA update any existing
> registry or create any new registry=2C but includes information that
> affects the IANA=2C which:
>=20
> * includes specific guidelines for Expert Reviewers appointed
>   under the IANA considerations of [RFC3575]
> * includes guidelines that recommend against self allocation from
>   ...
>=20
>   Alan DeKok.

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






looks good.


>=3B Date: Fri=2C 4 Sep 2009 10:13:07 +0200
>=
=3B From: aland@deployingradius.com
>=3B To: bernard_aboba@hotmail.com=

>=3B CC: radiusext@ops.ietf.org
>=3B Subject: Re: Issue 311: IES=
G DISCUSS comments
>=3B 
>=3B Bernard Aboba wrote:
>=3B >=
=3B You might also mention that firewalls and other filtering devices often=

>=3B >=3B discard fragments.
>=3B 
>=3B   OK.
>=3B <=
br>>=3B >=3B Jari is correct that allocation requests will be handled a=
ccording to
>=3B >=3B RFC 3575=2C
>=3B >=3B but as part of th=
e Expert Review process=2C Design Guidelines will
>=3B >=3B presumab=
ly be
>=3B >=3B consulted.  So while self-allocation is certainly no=
t a good practice=2C
>=3B >=3B the whole
>=3B >=3B point of I=
ANA allocation is to enable consistent allocation.  Perhaps
>=3B >=
=3B the text
>=3B >=3B can be clear that the recommendations are rel=
evant to Expert Reviewers
>=3B >=3B appointed under the IANA conside=
rations of RFC 3575=2C not for IANA itself.
>=3B 
>=3B   OK.  I s=
uggest adding a first bullet about this point to the IANA
>=3B conside=
rations section:
>=3B 
>=3B ...
>=3B This document does not =
require that the IANA update any existing
>=3B registry or create any =
new registry=2C but includes information that
>=3B affects the IANA=2C=
 which:
>=3B 
>=3B * includes specific guidelines for Expert Revi=
ewers appointed
>=3B   under the IANA considerations of [RFC3575]
&=
gt=3B * includes guidelines that recommend against self allocation from
=
>=3B   ...
>=3B 
>=3B   Alan DeKok.

=

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Fri Sep  4 15:54:30 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D280328C126 for ; Fri,  4 Sep 2009 15:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.285
X-Spam-Level: 
X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kc8HH8eGgs6 for ; Fri,  4 Sep 2009 15:54:30 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D54A828C125 for ; Fri,  4 Sep 2009 15:54:29 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mjgej-00052l-Cl for radiusext-data0@psg.com; Fri, 04 Sep 2009 21:49:17 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjfjR-000KWT-TJ for radiusext@ops.ietf.org; Fri, 04 Sep 2009 20:54:06 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 505D7123445D; Fri,  4 Sep 2009 22:50:04 +0200 (CEST)
Message-ID: <4AA17D7B.1000108@deployingradius.com>
Date: Fri, 04 Sep 2009 22:50:03 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document
References:  <4A9FC45A.7090702@deployingradius.com>  <4AA0CDEE.8040109@deployingradius.com>  <4AA14E8E.5030009@deployingradius.com> 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
>> The design guidelines document can talk about things that exist today.
>> if other documents add new RADIUS functionality, they can mention that
>> they update the design guidelines document.
> 
> Seems reasonable to me.  Could you post a proposal on text to be deleted?

  All text that references [EXTEN], or extended attributes. A quick pass
through the document yeilds:

   Specifications that do not follow the
   guidelines articulated herein or in [EXTEN] are NOT RECOMMENDED.
->
   Specifications that do not follow the
   guidelines articulated herein are NOT RECOMMENDED.
   Changes to the RADIUS data model are NOT
   RECOMMENDED, but if performed, SHOULD follow the IETF process.

  i.e. we can't retro-actively forbid the various SDOs from adding all
kinds of stuff to the data model.


   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.  New attributes SHOULD use the grouping
   method described in [EXTEN].
->
   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.


2.2.  Extended RADIUS Attributes
->
	


  In Section 2.3:

   If additional functionality is required, the format defined in
   [EXTEN] SHOULD be used, with a non-zero Vendor-Id field.
->
	
	


  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep  6 13:49:19 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E463A6947 for ; Sun,  6 Sep 2009 13:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.355
X-Spam-Level: 
X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4sTAzeuMSpl for ; Sun,  6 Sep 2009 13:49:18 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E673C3A6852 for ; Sun,  6 Sep 2009 13:49:17 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkOCc-000BBm-4b for radiusext-data0@psg.com; Sun, 06 Sep 2009 20:19:10 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkNuY-0009pe-NY for radiusext@ops.ietf.org; Sun, 06 Sep 2009 20:04:31 +0000
Received: by core3.amsl.com (Postfix, from userid 0) id 2B9AC3A699F; Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep  6 13:56:47 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136E83A681C for ; Sun,  6 Sep 2009 13:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.355
X-Spam-Level: 
X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJdGZFcbwSXQ for ; Sun,  6 Sep 2009 13:56:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C61993A6810 for ; Sun,  6 Sep 2009 13:56:46 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkOcT-000E1q-PZ for radiusext-data0@psg.com; Sun, 06 Sep 2009 20:45:53 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkODg-000BIb-8M for radiusext@ops.ietf.org; Sun, 06 Sep 2009 20:24:16 +0000
Received: by core3.amsl.com (Postfix, from userid 0) id 2B9AC3A699F; Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep  6 15:07:20 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F8B3A682B for ; Sun,  6 Sep 2009 15:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.214
X-Spam-Level: 
X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=1.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg28YOP5V3RE for ; Sun,  6 Sep 2009 15:06:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEC243A67F5 for ; Sun,  6 Sep 2009 15:06:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkOuS-000FkW-RC for radiusext-data0@psg.com; Sun, 06 Sep 2009 21:04:28 +0000
Received: from [64.170.98.32] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkOGa-000BV6-Em for radiusext@ops.ietf.org; Sun, 06 Sep 2009 20:27:16 +0000
Received: by core3.amsl.com (Postfix, from userid 0) id 2B9AC3A699F; Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep  6 15:15:54 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9DF3A6832 for ; Sun,  6 Sep 2009 15:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.214
X-Spam-Level: 
X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=1.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JhjAEt9ESv6 for ; Sun,  6 Sep 2009 15:15:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74E543A682B for ; Sun,  6 Sep 2009 15:15:54 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkP3D-000Grv-EH for radiusext-data0@psg.com; Sun, 06 Sep 2009 21:13:31 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkOlY-000ErR-C0 for radiusext@ops.ietf.org; Sun, 06 Sep 2009 20:59:16 +0000
Received: by core3.amsl.com (Postfix, from userid 0) id 2B9AC3A699F; Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep  7 12:20:43 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFE13A691A for ; Mon,  7 Sep 2009 12:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.103
X-Spam-Level: **
X-Spam-Status: No, score=2.103 tagged_above=-999 required=5 tests=[AWL=-1.555, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r4RxRsR0UDc for ; Mon,  7 Sep 2009 12:20:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93B943A68B7 for ; Mon,  7 Sep 2009 12:20:42 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkjRv-000F3u-VN for radiusext-data0@psg.com; Mon, 07 Sep 2009 19:00:23 +0000
Received: from [65.55.116.16] (helo=blu0-omc1-s5.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mkj3H-000Cdg-MK for radiusext@ops.ietf.org; Mon, 07 Sep 2009 18:34:55 +0000
Received: from BLU137-W24 ([65.55.116.8]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 11:34:54 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_51481470-7a9c-4acb-9722-06e329bc25e8_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #1407 (RFC 5176)
Date: Mon, 7 Sep 2009 11:34:55 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Sep 2009 18:34:54.0428 (UTC) FILETIME=[E4B2A9C0:01CA2FE9]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_51481470-7a9c-4acb-9722-06e329bc25e8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


My recommendation is that this errata be accepted.  As Avi points out=2C=20
the CUI attribute is opaque and therefore not parseable by the Dynamic
Authorization Server.=20


Status: Reported

Type: Technical



Reported By: Avi Lior

Date Reported: 2008-04-09


Section 6.1 says:


Typically=2C the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name or Chargeable-User-Identity Attribute=2C and determine the
   corresponding RADIUS servers in the realm routing tables.

It should say:

Typically=2C the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name and determine the
   corresponding RADIUS servers in the realm routing tables.

Notes:


Chargeable-User-Identity Attribute defined in RFC4372 does not allow
any entity other then the home network to parse the CUI attribute. It
is in essence opaque. Here is the text:

"RADIUS entities other than the Home RADIUS

      server MUST treat the CUI content as an opaque token=2C and SHOULD

      NOT perform operations on its content other than a binary equality

      comparison test=2C between two instances of CUI."






 EMAILING FOR THE GREATER GOOD
Join me=

--_51481470-7a9c-4acb-9722-06e329bc25e8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






My recommendation is that this errata be accepted. =3B As Avi points=
 out=2C 
the CUI attribute is opaque and therefore not parseable by the =
Dynamic
Authorization Server. 


Status: Reported

Type: Technical



Reported By: Avi Lior

Date Reported: 2008-04-09


Section 6.1 says:



Typically=2C the Dynamic Authorization Server will e=
xtract the realm
   from the Network Access Identifier [RFC4282] include=
d within the
   User-Name or Chargeable-User-Identity Attribute=2C and d=
etermine the
   corresponding RADIUS servers in the realm routing tables=
.

It should say:


Typically=2C the Dynamic Authorization Server will e=
xtract the realm
   from the Network Access Identifier [RFC4282] include=
d within the
   User-Name and determine the
   corresponding RADIUS s=
ervers in the realm routing tables.

Notes:



Chargeable-User-Identity Attribute defined in RFC4372 does not allow
any entity other then the home network to parse the CUI attribute. It
is in essence opaque. Here is the text:

"RADIUS entities other than the Home RADIUS

      server MUST treat the CUI content as an opaque token=2C and SHOULD
      NOT perform operations on its content other than a binary equality
      comparison test=2C between two instances of CUI."







3D"i'm" EMAILING FOR THE G=
REATER GOOD
Join me<=
/td>

=

--_51481470-7a9c-4acb-9722-06e329bc25e8_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep  7 14:00:21 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7228F3A6A0F for ; Mon,  7 Sep 2009 14:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.247
X-Spam-Level: 
X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRsyOQv1fliE for ; Mon,  7 Sep 2009 14:00:20 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7776A3A67DF for ; Mon,  7 Sep 2009 14:00:20 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MklDv-0002jm-L8 for radiusext-data0@psg.com; Mon, 07 Sep 2009 20:54:03 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MkknO-000Oca-5x for radiusext@ops.ietf.org; Mon, 07 Sep 2009 20:26:38 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id ED9B412345DC for ; Mon,  7 Sep 2009 22:26:36 +0200 (CEST)
Message-ID: <4AA56C7C.2070203@deployingradius.com>
Date: Mon, 07 Sep 2009 22:26:36 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: 'radext mailing list' 
Subject: Test
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

  Is the mailing list fixed?  My earlier posts aren't in the archives...

  Did anyone other than Bernard see my comments on the issues in the
guidelines document?

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep  7 15:01:26 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38CD3A6ACE for ; Mon,  7 Sep 2009 15:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRqXtv+cwytw for ; Mon,  7 Sep 2009 15:01:25 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3EA83A6ACD for ; Mon,  7 Sep 2009 15:01:25 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mkm3J-0007nf-95 for radiusext-data0@psg.com; Mon, 07 Sep 2009 21:47:09 +0000
Received: from [209.85.221.202] (helo=mail-qy0-f202.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MklSz-0004kp-Jj for radiusext@ops.ietf.org; Mon, 07 Sep 2009 21:09:37 +0000
Received: by qyk40 with SMTP id 40so2298921qyk.9 for ; Mon, 07 Sep 2009 14:09:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ioGZ2K7UtcsVS6zgj0VVXnCW+dQ6PAkcmjmgCQKZxsE=; b=mt3LOR//7h8vkq1xTW0Z1LktdXp5yPU9p1ml/wcoAfSYR13v0qiQo2YI7EvJzquXk8 w+XmIYGG1Nv8UuHEqnX83JOApVSXxvJILmbnpVibYPug/yUPmc8hu8woQ4KBf4UrD3X5 j+AB+jD475kixIxZr6R2bazJOydfn2lyDr4Zw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eBJ9ioGz2rI2YlI5+BBCrBF9/QluBUP8F5b27dLeyQqt7/5TpURpiEM5F/OMJKbu/4 aYUkp4u5tjY4s+TgHHUwOoCtOdFRjd8QvWKQ4ySOdPHNaJYGiz/7xjR+v4efBkeRD6mq lsMnYpFkp4BkPAEF+QNO2xVEfSuc1f7aZkeQ8=
MIME-Version: 1.0
Received: by 10.224.92.143 with SMTP id r15mr9342578qam.105.1252357776862;  Mon, 07 Sep 2009 14:09:36 -0700 (PDT)
In-Reply-To: <4AA56C7C.2070203@deployingradius.com>
References: <4AA56C7C.2070203@deployingradius.com>
Date: Mon, 7 Sep 2009 17:09:36 -0400
Message-ID: 
Subject: Re: Test
From: Greg Weber 
To: Alan DeKok 
Cc: radext mailing list 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

On Mon, Sep 7, 2009 at 4:26 PM, Alan DeKok wrote=
:
> =A0Is the mailing list fixed? =A0My earlier posts aren't in the archives.=
..
>
> =A0Did anyone other than Bernard see my comments on the issues in the
> guidelines document?

Yes.  They appear to have gone to the list, but not the archive.

Greg

>
> =A0Alan DeKok.
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 01:27:08 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882AA3A69BA for ; Tue,  8 Sep 2009 01:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.69
X-Spam-Level: 
X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[AWL=-1.579, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEdkBCrE6ouv for ; Tue,  8 Sep 2009 01:27:07 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 767AE3A69E6 for ; Tue,  8 Sep 2009 01:27:07 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mkw06-000HKV-O3 for radiusext-data0@psg.com; Tue, 08 Sep 2009 08:24:30 +0000
Received: from [217.108.152.42] (helo=R-MAIL2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mkvzm-000HHi-0o for radiusext@ops.ietf.org; Tue, 08 Sep 2009 08:24:16 +0000
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 10:24:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Test
Date: Tue, 8 Sep 2009 10:24:05 +0200
Message-ID: 
In-Reply-To: <4AA56C7C.2070203@deployingradius.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Test
Thread-Index: Acov/lV3Bqknp3beRJG+omKWHCt6TAAX1stQ
References: <4AA56C7C.2070203@deployingradius.com>
From: 
To: , 
X-OriginalArrivalTime: 08 Sep 2009 08:24:07.0079 (UTC) FILETIME=[BB96BB70:01CA305D]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

I have them in my inbox! ;)

Lionel=20

> -----Message d'origine-----
> De : owner-radiusext@ops.ietf.org=20
> [mailto:owner-radiusext@ops.ietf.org] De la part de Alan DeKok
> Envoy=E9 : lundi 7 septembre 2009 22:27
> =C0 : 'radext mailing list'
> Objet : Test
>=20
>=20
>   Is the mailing list fixed?  My earlier posts aren't in the=20
> archives...
>=20
>   Did anyone other than Bernard see my comments on the issues=20
> in the guidelines document?
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: 
>=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:03:35 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFAE28C111 for ; Tue,  8 Sep 2009 08:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.993
X-Spam-Level: 
X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shJ1rpbMWVDA for ; Tue,  8 Sep 2009 08:03:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A57FD3A68C4 for ; Tue,  8 Sep 2009 08:03:34 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Ae-0000B0-HK for radiusext-data0@psg.com; Tue, 08 Sep 2009 14:59:48 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2AT-0000AH-Dw for radiusext@ops.ietf.org; Tue, 08 Sep 2009 14:59:45 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 8685512345DC; Tue,  8 Sep 2009 16:59:31 +0200 (CEST)
Message-ID: <4AA67153.2090506@deployingradius.com>
Date: Tue, 08 Sep 2009 16:59:31 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: RADIUS Errata #1407 (RFC 5176)
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> *My recommendation is that this errata be accepted.  As Avi points out,
> the CUI attribute is opaque and therefore not parseable by the Dynamic
> Authorization Server.

  I agree.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:12:55 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECE43A69C7 for ; Tue,  8 Sep 2009 08:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.352
X-Spam-Level: *
X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMJt7pXWBNui for ; Tue,  8 Sep 2009 08:12:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 290D53A69B4 for ; Tue,  8 Sep 2009 08:12:54 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2KY-00015N-Ik for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:10:02 +0000
Received: from [65.55.116.40] (helo=blu0-omc1-s29.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Jv-00012N-I3 for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:09:51 +0000
Received: from BLU137-W24 ([65.55.116.9]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:09:23 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_3901da34-350f-4435-b4be-0507c9478d20_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #867 (RFC 4668)
Date: Tue, 8 Sep 2009 08:09:23 -0700
Importance: Normal
In-Reply-To: 
References: 
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 15:09:23.0323 (UTC) FILETIME=[59331CB0:01CA3096]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_3901da34-350f-4435-b4be-0507c9478d20_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










[BA] IMHO=2C Alfred is correct that RFC 4668 covers both IPv4 and IPv6.=20
Since the abstract makes this clear=2C I don't think that the title needs t=
o be changed.=20

With respect to the term "MIB module"=2C I would agree with Alfred that the=
 term
"MIB" would have been more appropriate.

Overall I'd recommend that this errata be accepted "Pending Revision".=20


Status: Reported

Type: Editorial



Reported By: Alfred Hoenes

Date Reported: 2006-11-06




misleading RFC title=2C including abuse of defined terms
(for RFCs 4668 - 4671)

IMHO=2C the RFC titles=2C "RADIUS ... MIB for IPv6" are misleading.
In fact=2C the new RFCs extend the RADIUS MIB modules to cover
IPv6=2C but they are not IPv6 specific!
Perhaps=2C better wording would have been "... for IPv4 and IPv6".

Furthermore=2C a very 'popular' clash of terms shines up here.
As specified in RFC 3410 and Part 1 of STD 62=2C RFC 3411=2C and
re-stated in the boilerplate Section 3=2C "The Internet-Standard
Management Framework"=2C of all four RFCs=2C there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus=2C throughout the titles and the text bodies of the RFCs=2C the
proper term=2C "RADIUS ... MIB module" should be used instead of the
rather sluggish "RADIUS ... MIB".



--_3901da34-350f-4435-b4be-0507c9478d20_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














[BA] IMHO=2C Alfred is correct that RFC 4668 covers both IPv4 and IPv6. =

Since the abstract makes this clear=2C I don't think that the title nee=
ds to be changed. 

With respect to the term "MIB module"=2C I would =
agree with Alfred that the term
"MIB" would have been more appropriate.<=
br>
Overall I'd recommend that this errata be accepted "Pending Revision=
". 


Status: Reported

Type: Editorial



Reported By: Alfred Hoenes

Date Reported: 2006-11-06





misleading RFC title=2C including abuse of define=
d terms
(for RFCs 4668 - 4671)

IMHO=2C the RFC titles=2C "RADIUS =
... MIB for IPv6" are misleading.
In fact=2C the new RFCs extend the RAD=
IUS MIB modules to cover
IPv6=2C but they are not IPv6 specific!
Perh=
aps=2C better wording would have been "... for IPv4 and IPv6".

Furth=
ermore=2C a very 'popular' clash of terms shines up here.
As specified i=
n RFC 3410 and Part 1 of STD 62=2C RFC 3411=2C and
re-stated in the boil=
erplate Section 3=2C "The Internet-Standard
Management Framework"=2C of =
all four RFCs=2C there's just one single
Management Information Base (MI=
B) comprised of various "MIB modules".
Thus=2C throughout the titles and=
 the text bodies of the RFCs=2C the
proper term=2C "RADIUS ... MIB modul=
e" should be used instead of the
rather sluggish "RADIUS ... MIB".



=

--_3901da34-350f-4435-b4be-0507c9478d20_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:13:22 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990AB3A69B4 for ; Tue,  8 Sep 2009 08:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.364
X-Spam-Level: 
X-Spam-Status: No, score=0.364 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy7Uh9pQteWx for ; Tue,  8 Sep 2009 08:13:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B6C33A68B4 for ; Tue,  8 Sep 2009 08:13:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Lu-0001DQ-HH for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:11:26 +0000
Received: from [65.55.116.18] (helo=blu0-omc1-s7.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Kz-00018Y-4O for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:10:56 +0000
Received: from BLU137-W34 ([65.55.116.7]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:10:29 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #816 (RFC 4282)
Date: Tue, 8 Sep 2009 08:10:28 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 15:10:29.0236 (UTC) FILETIME=[807CA340:01CA3096]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











My recommendation is that this errata be accepted "Pending Update".=20



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2005-12-18



=20

Unfortunately=2C the text of that RFC does not fully reflect the
established state of the IETF standards=2C by referring to obsolete
documents (e.g.=2C ex STD 10=2C RFC 821) and ignoring effective updates=2C
e.g.=2C STD 3=2C RFC 1123=2C and RFC 2821.

In particular=2C the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.

This is not true!
The pretended deviation in fact reflects the current standards.

The modification to RFC 952=2C RFC 821=2C et al. has already been
introduced into the IETF Standards by STD 3=2C RFC 1123 (Host
Requirements=2C Part II)=2C published 16 years ago=2C in October 1989.
Section 2.1 of that RFC=2C on page 13=2C says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

Therefore=2C it would have been strongly advisable to point out
on page 6 of RFC 4282=2C in Section 2.2=2C first bullet=2C that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO=2C it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs=2C AVPs=2C -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type=2C Length and Value fields=2C instead of just giving
the size of the Value (payload) field=3B the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !


Similarly=2C RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP=2C the only comparable protocol named in=20
RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws=2C among
      other issues=2C and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols=2C in a manner that does not make clear the distinction.
The continued unreflected use of PPTP=2C in particular=2C is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet.  We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it=2C and push the evolved standards!



It should say:

[see above]

Notes:


from pending


--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















My recommendation is that this errata be accepted "Pending Update". 
=



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2005-12-18



 =3B


Unfortunately=2C the text of that RFC does not fu=
lly reflect the
established state of the IETF standards=2C by referring =
to obsolete
documents (e.g.=2C ex STD 10=2C RFC 821) and ignoring effect=
ive updates=2C
e.g.=2C STD 3=2C RFC 1123=2C and RFC 2821.

In part=
icular=2C the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasi=
zes making a deviation from established standards
for host / domain name=
s.

This is not true!
The pretended deviation in fact reflects the=
 current standards.

The modification to RFC 952=2C RFC 821=2C et al.=
 has already been
introduced into the IETF Standards by STD 3=2C RFC 112=
3 (Host
Requirements=2C Part II)=2C published 16 years ago=2C in October=
 1989.
Section 2.1 of that RFC=2C on page 13=2C says:

    "One as=
pect of host name syntax is hereby changed: the
     restriction on the =
first character is relaxed to allow
     either a letter or a digit. Hos=
t software MUST support
     this more liberal syntax."

and conti=
nues saying:

    "Host software MUST handle host names of up to 63 c=
haracters
     and SHOULD handle host names of up to 255 characters."
Therefore=2C it would have been strongly advisable to point out
on =
page 6 of RFC 4282=2C in Section 2.2=2C first bullet=2C that the
named r=
ules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO=2C it =
is a fundamental design flaw of RADIUS and certain
other protocols using=
 TLVs=2C AVPs=2C -- or however similar protocol
objects are named -- to =
specify that the 'length' information
(being stored in a single octet) i=
s to comprise the cumulative
size of the Type=2C Length and Value fields=
=2C instead of just giving
the size of the Value (payload) field=3B the =
latter solution would
always allow to fully exhaust the total range of a=
n 8-bit unsigned
Length and thereby allow payload octet strings of size =
0..255 !


Similarly=2C RFC 4282 ignores the standardization state=
 of the
proprietary historic tunnelling protocols that have served as'precursors with major deficiencies to learn from' for the
development =
of L2TP=2C the only comparable protocol named in 
RFC 4282 that is on th=
e IETF Standards Track.

  o   L2F [RFC2341] has been published for i=
nformation only
      as a Historic RFC 'ab initio'.

  o   PPTP [=
RFC2637] has purposely been rejected by the IETF --
      because of its=
 well known significant security flaws=2C among
      other issues=2C an=
d the Informational RFC 2637 has been
      published with a very clear =
IESG Note to this end.

I am surprised that a new Standards Track RFC=
 is getting published
that repeatedly refers to obsolete protocols equal=
ly as to official
protocols=2C in a manner that does not make clear the =
distinction.
The continued unreflected use of PPTP=2C in particular=2C i=
s seen by
major security consultants as 'one of the most widespread troj=
an
horses' in the current Internet.  We should do everything to
commu=
nicate and emphasize the 1998/1999 decisions of the IETF and
IESG and th=
e reasons behind it=2C and push the evolved standards!



It should say:


[see above]

Notes:



from pending

=

=


=

--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:13:41 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAD53A68B4 for ; Tue,  8 Sep 2009 08:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.134
X-Spam-Level: **
X-Spam-Status: No, score=2.134 tagged_above=-999 required=5 tests=[AWL=-1.519, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpeHCVQ1V98j for ; Tue,  8 Sep 2009 08:13:40 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4E5F28C160 for ; Tue,  8 Sep 2009 08:13:40 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2LO-0001AP-5g for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:10:54 +0000
Received: from [65.55.116.48] (helo=blu0-omc1-s37.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2KZ-00015Q-4C for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:10:22 +0000
Received: from BLU137-W1 ([65.55.116.8]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:10:03 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_ffb47776-6c14-4d11-a073-92c4bb88ac6b_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #1326 (RFC 5090)
Date: Tue, 8 Sep 2009 08:10:02 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 15:10:03.0171 (UTC) FILETIME=[70F36F30:01CA3096]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Errata ID: 1326


My recommendation is that this errata be accepted "Pending Update".=20



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2008-02-17



Throughout the document=2C when it says:


a)       header

b)       headers

c)       Header

It should say:

a)       header field

b)       header fields

c)       Header Field

Notes:


As a Standards Track document=2C RFC 5090 should use established

IETF standard terminology=2C and not fall back to common sluggish

and confusing terminology.  Concise Ref.:  RFC 4249=2C Section 3.1.1.



There are 24 instances of case a) throughout the RFC=3B

only Section 3.20 makes proper use of the IETF standard

terminology=3B case b) occurs twice in the RFC=3B

case c) applies to the title of Section 2.1.3.







 EMAILING FOR THE GREATER GOOD
Join me=

--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Errata ID: 1326


My recommendation is that this errata be accepted "Pending Update". 
=



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2008-02-17



Throughout the document=2C when it says:



a)       header

b)       headers

c)=
       Header

It should say:


a)       header field

b)       header fiel=
ds

c)       Header Field

Notes:



As a Standards Track document=2C RFC 5090 should use established

IETF standard terminology=2C and not fall back to common sluggish

and confusing terminology.  Concise Ref.:  RFC 4249=2C Section 3.1.1.



There are 24 instances of case a) throughout the RFC=3B

only Section 3.20 makes proper use of the IETF standard

terminology=3B case b) occurs twice in the RFC=3B

case c) applies to the title of Section 2.1.3.









3D"i'm" EMAILING FOR THE G=
REATER GOOD
Join me<=
/td>

=

--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:13:46 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA21328C160 for ; Tue,  8 Sep 2009 08:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.157
X-Spam-Level: *
X-Spam-Status: No, score=1.157 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRNfZrbolsO6 for ; Tue,  8 Sep 2009 08:13:46 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5D8B3A69C5 for ; Tue,  8 Sep 2009 08:13:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2MS-0001Gw-CI for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:12:00 +0000
Received: from [65.55.116.19] (helo=blu0-omc1-s8.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2LP-0001AT-F2 for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:11:33 +0000
Received: from BLU137-W24 ([65.55.116.9]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:10:55 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_154e7599-aefa-4c44-b34b-e27990b1da86_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #757 (RFC 4282)
Date: Tue, 8 Sep 2009 08:10:55 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 15:10:55.0261 (UTC) FILETIME=[8FFFBCD0:01CA3096]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_154e7599-aefa-4c44-b34b-e27990b1da86_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










My recommendation is that this errata be accepted.=20
Status: Reported

Type: Technical



Reported By: Peter Koch

Date Reported: 2005-12-13



Section 2.6 says:


   The BNF of the realm portion allows the realm to begin with a digit=2C
   which is not permitted by the BNF described in [RFC1035].  This
   change was made to reflect current practice=3B although not permitted
   by the BNF described in [RFC1035]=2C Fully Qualified Domain Names
   (FQDNs) such as 3com.com are commonly used and accepted by current
   software.

It should say:

[not supplied]

Notes:


section 2.6 missed the update of the hostname syntax in

RFC 1123=2C section 2.1.



RFC 1123 (STD 3) 2.1 allows labels starting with a 

in fully qualified domain names of a host=2C RFC 1035 (STD 13)

2.3.1 still wants labels starting with a .





 EMAILING FOR THE GREATER GOOD
Join me=

--_154e7599-aefa-4c44-b34b-e27990b1da86_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














My recommendation is that this errata be accepted. 
Status: Re=
ported

Type: Technical



Reported By: Peter Koch

Date Reported: 2005-12-13



Section 2.6 says:



   The BNF of the realm portion allows the realm =
to begin with a digit=2C
   which is not permitted by the BNF described =
in [RFC1035].  This
   change was made to reflect current practice=3B al=
though not permitted
   by the BNF described in [RFC1035]=2C Fully Quali=
fied Domain Names
   (FQDNs) such as 3com.com are commonly used and acce=
pted by current
   software.

It should say:


[not supplied]

Notes:



section 2.6 missed the update of the hostname syntax in

RFC 1123=2C section 2.1.



RFC 1123 (STD 3) 2.1 allows labels starting with a <=3Bdigit>=3B

in fully qualified domain names of a host=2C RFC 1035 (STD 13)

2.3.1 still wants labels starting with a <=3Bletter>=3B.






=

3D"i'm" EMAILING FOR THE GREAT=
ER GOOD
Join me

=

--_154e7599-aefa-4c44-b34b-e27990b1da86_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:14:37 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADB228C1E6 for ; Tue,  8 Sep 2009 08:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.167
X-Spam-Level: **
X-Spam-Status: No, score=2.167 tagged_above=-999 required=5 tests=[AWL=-1.491, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J26LKMRU84Th for ; Tue,  8 Sep 2009 08:14:36 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AC823A68B4 for ; Tue,  8 Sep 2009 08:14:36 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Mt-0001K1-S3 for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:12:27 +0000
Received: from [65.55.116.20] (helo=blu0-omc1-s9.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Lo-0001Ct-2R for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:11:58 +0000
Received: from BLU137-W6 ([65.55.116.8]) by blu0-omc1-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:11:20 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #753 (RFC 4282)
Date: Tue, 8 Sep 2009 08:11:19 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 15:11:20.0044 (UTC) FILETIME=[9EC552C0:01CA3096]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Anyone have an opinion on this one? As I recall=2C the use of 'FF' was inte=
ntional.=20


Status: Reported

Type: Technical



Reported By: Frank Ellermann

Date Reported: 2006-08-14



Section 2.1 says:


   c           =3D/ %x80-FF =3B UTF-8-Octet      allowed (not in RFC 2486)
                          =3B Where UTF-8-octet is any octet in the
                          =3B multi-octet UTF-8 representation of a
                          =3B unicode codepoint above %x7F.
                          =3B Note that c must also satisfy rules in
                          =3B Section 2.4=2C including=2C for instance=2C
                          =3B checking that no prohibited output is
                          =3B used (see also Section 2.3 of
                          =3B [RFC4013]).
   x           =3D  %x00-FF =3B all 128 ASCII characters=2C no exception=3B
                          =3B as well as all UTF-8-octets as defined
                          =3B above (this was not allowed in
                          =3B RFC 2486).  Note that x must nevertheless
                          =3B again satisfy the Section 2.4 rules.

It should say:

[see below]

Notes:


Shouldn't that be s/FF/F4/ as in STD 63=2C or maybe s/FF/FD/ ?







 EMAILING FOR THE GREATER GOOD
Join me=

--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















Anyone have an opinion on this one? As I recall=2C the use of 'FF' was inte=
ntional. 


Status: Reported

Type: Technical



Reported By: Frank Ellermann

Date Reported: 2006-08-14



Section 2.1 says:



   c           =3D/ %x80-FF =3B UTF-8-Octet      =
allowed (not in RFC 2486)
                          =3B Where UTF-8-octe=
t is any octet in the
                          =3B multi-octet UTF-8 re=
presentation of a
                          =3B unicode codepoint above =
%x7F.
                          =3B Note that c must also satisfy rules =
in
                          =3B Section 2.4=2C including=2C for instanc=
e=2C
                          =3B checking that no prohibited output is=

                          =3B used (see also Section 2.3 of
        =
                  =3B [RFC4013]).
   x           =3D  %x00-FF =3B all 12=
8 ASCII characters=2C no exception=3B
                          =3B as w=
ell as all UTF-8-octets as defined
                          =3B above (=
this was not allowed in
                          =3B RFC 2486).  Note t=
hat x must nevertheless
                          =3B again satisfy the =
Section 2.4 rules.

It should say:


[see below]

Notes:



Shouldn't that be s/FF/F4/ as in STD 63=2C or maybe s/FF/FD/ ?









3D"i'm" EMAILING FOR THE G=
REATER GOOD
Join me<=
/td>

=

--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:16:45 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4355A3A6A58 for ; Tue,  8 Sep 2009 08:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.413
X-Spam-Level: *
X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuMQ5tw+p6sX for ; Tue,  8 Sep 2009 08:16:44 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B4F43A6A47 for ; Tue,  8 Sep 2009 08:16:44 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2PC-0001eu-7u for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:14:50 +0000
Received: from [65.55.116.19] (helo=blu0-omc1-s8.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Ow-0001cx-GG for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:14:48 +0000
Received: from BLU137-W24 ([65.55.116.7]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 08:14:34 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG mailing list issues
Date: Tue, 8 Sep 2009 08:14:34 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 15:14:34.0407 (UTC) FILETIME=[129EC370:01CA3097]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










A number of you have sent me email noting that one or more of the following=
 problems:

a. Your posts are not making it to the list=2C when sent from a subscribed =
email address=3B
b. Your posts are not making it to the list=2C when sent from an unsubscrib=
ed email address=3B
c. You are not receiving posts sent to the list=3B

Based on my own experience and examination of the logs=2C the RADEXT WG lis=
t appears to have stopped functioning this weekend and messages sent to the=
 list during that time were not sent out.  The list is now functioning agai=
n=2C but the archive has remained down since September 2=2C 2009.

Be aware that the RADEXT WG list only allows subscribers to post=3B non-sub=
scriber emails are bounced. =20

If you have sent mail to the list that was not sent out=2C please resend it=
.=20



--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














A number of you have sent me email noting that one or more of the following=
 problems:

a. Your posts are not making it to the list=2C when sent =
from a subscribed email address=3B
b. Your posts are not making it to th=
e list=2C when sent from an unsubscribed email address=3B
c. You are not=
 receiving posts sent to the list=3B

Based on my own experience and =
examination of the logs=2C the RADEXT WG list appears to have stopped funct=
ioning this weekend and messages sent to the list during that time were not=
 sent out. =3B The list is now functioning again=2C but the archive has=
 remained down since September 2=2C 2009.

Be aware that the RADEXT W=
G list only allows subscribers to post=3B non-subscriber emails are bounced=
. =3B 

If you have sent mail to the list that was not sent out=
=2C please resend it. 

<=
tbody>


=

--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:20:44 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE49B3A6979 for ; Tue,  8 Sep 2009 08:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.968
X-Spam-Level: 
X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwMOEHwITM0k for ; Tue,  8 Sep 2009 08:20:44 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 382CE3A68EB for ; Tue,  8 Sep 2009 08:20:44 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Rn-0001x6-Ba for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:17:31 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2Rc-0001vo-SJ for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:17:29 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 0300B12345DC; Tue,  8 Sep 2009 17:17:19 +0200 (CEST)
Message-ID: <4AA6757F.7010402@deployingradius.com>
Date: Tue, 08 Sep 2009 17:17:19 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: RADIUS Errata #816 (RFC 4282)
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

  Could we not file an errata against 4282 saying  "This document is
nearly completely wrong: no one does what it recommends".

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:39:20 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D0028C179 for ; Tue,  8 Sep 2009 08:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.039
X-Spam-Level: 
X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7m84B3ZYYyn for ; Tue,  8 Sep 2009 08:39:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E60963A695A for ; Tue,  8 Sep 2009 08:39:14 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2ko-0003jZ-32 for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:37:10 +0000
Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2kR-0003hy-91 for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:37:03 +0000
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n88FZMqf026649; Tue, 8 Sep 2009 08:35:23 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n88FZL4e026640; Tue, 8 Sep 2009 08:35:21 -0700 (PDT)
Date: Tue, 8 Sep 2009 08:35:21 -0700 (PDT)
Message-Id: <200909081535.n88FZL4e026640@boreas.isi.edu>
To: bernarda@microsoft.com, mbeadles@endforce.com, jari.arkko@ericsson.com, pasi.eronen@nokia.com, dromasca@avaya.com, rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com
Subject: [Technical Errata Reported] RFC4282 (1848)
From: RFC Errata System 
Cc: aland@freeradius.org, radiusext@ops.ietf.org, rfc-editor@rfc-editor.org
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: web-usrn@boreas.isi.edu
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1848

--------------------------------------
Type: Technical
Reported by: Alan DeKok 

Section: 2.4

Original Text
-------------
   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

Corrected Text
--------------
  o Normalization is, in general, a bad idea.

Notes
-----
Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set information is included with the text.  And that information is not included with the username or realm.

In addition, not all systems will treat "User" the same as "user".  The decision about how to
compare user names is site specific.  User name comparisons SHOULD NOT be performed on
any system other than the final one that performs user authentication.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:41:09 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61FC13A68AF for ; Tue,  8 Sep 2009 08:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.039
X-Spam-Level: 
X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLkTmwMMoB3v for ; Tue,  8 Sep 2009 08:41:08 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F92E3A67B3 for ; Tue,  8 Sep 2009 08:41:08 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2mE-0003v0-K9 for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:38:38 +0000
Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2m3-0003tt-HB for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:38:35 +0000
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n88Fb4Mw027222; Tue, 8 Sep 2009 08:37:05 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n88Fb41h027221; Tue, 8 Sep 2009 08:37:04 -0700 (PDT)
Date: Tue, 8 Sep 2009 08:37:04 -0700 (PDT)
Message-Id: <200909081537.n88Fb41h027221@boreas.isi.edu>
To: bernarda@microsoft.com, mbeadles@endforce.com, jari.arkko@ericsson.com, pasi.eronen@nokia.com, dromasca@avaya.com, rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com
Subject: [Technical Errata Reported] RFC4282 (1849)
From: RFC Errata System 
Cc: aland@freeradius.org, radiusext@ops.ietf.org, rfc-editor@rfc-editor.org
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: web-usrn@boreas.isi.edu
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1849

--------------------------------------
Type: Technical
Reported by: Alan DeKok 

Section: 2.4

Original Text
-------------
   o  Bidirectional characters are handled as specified in Section 2.4
      of [RFC4013].

Corrected Text
--------------
  o Bidrectional characters are handled in a site-specific fashion

Notes
-----
The rules in [4013] have shortcomings.  Updates are in:

http://tools.ietf.org/html/draft-ietf-idnabis-bidi-05

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 08:43:57 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407873A695A for ; Tue,  8 Sep 2009 08:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.039
X-Spam-Level: 
X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTLNAn25vydT for ; Tue,  8 Sep 2009 08:43:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B73E3A687F for ; Tue,  8 Sep 2009 08:43:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2pu-0004O7-LP for radiusext-data0@psg.com; Tue, 08 Sep 2009 15:42:26 +0000
Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml2pb-0004KT-OL for radiusext@ops.ietf.org; Tue, 08 Sep 2009 15:42:23 +0000
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n88FcqCx027960; Tue, 8 Sep 2009 08:38:53 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n88Fcqfs027959; Tue, 8 Sep 2009 08:38:52 -0700 (PDT)
Date: Tue, 8 Sep 2009 08:38:52 -0700 (PDT)
Message-Id: <200909081538.n88Fcqfs027959@boreas.isi.edu>
To: bernarda@microsoft.com, mbeadles@endforce.com, jari.arkko@ericsson.com, pasi.eronen@nokia.com, dromasca@avaya.com, rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com
Subject: [Technical Errata Reported] RFC4282 (1850)
From: RFC Errata System 
Cc: aland@freeradius.org, radiusext@ops.ietf.org, rfc-editor@rfc-editor.org
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: web-usrn@boreas.isi.edu
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1850

--------------------------------------
Type: Technical
Reported by: Alan DeKok 

Section: 2.4

Original Text
-------------
   o  Unassigned code points are specified in Section 2.5 of [RFC4013].
      The use of unassigned code points is prohibited.

Corrected Text
--------------
  o Unassigned code points MUST be ignored

Notes
-----
Unassigned code points sometimes go through a process called "assignment".  This means that they suddenly become valid.

Implementations that forbid unassigned code points will not be updated when the standards change to assign them.  Therefore, they should ignore unassigned code points.

Happily, this is what all implementations do.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 10:07:38 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1B828C2C9 for ; Tue,  8 Sep 2009 10:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.218
X-Spam-Level: *
X-Spam-Status: No, score=1.218 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuCZijbOs2+5 for ; Tue,  8 Sep 2009 10:07:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1191328C2BB for ; Tue,  8 Sep 2009 10:07:37 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml48H-000FAr-O0 for radiusext-data0@psg.com; Tue, 08 Sep 2009 17:05:29 +0000
Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml47x-000F8X-2G for radiusext@ops.ietf.org; Tue, 08 Sep 2009 17:05:20 +0000
Received: (qmail 14844 invoked from network); 8 Sep 2009 17:05:02 -0000
Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 8 Sep 2009 17:05:02 -0000
From: "David B. Nelson" 
To: "'Alan DeKok'" 
Cc: 
References:  <4A9FC353.3050104@deployingradius.com>
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:05:35 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcosmghX1VPtkukgQc++FgVVO/oUfgEC9JYg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <4A9FC353.3050104@deployingradius.com>
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Sorry for the late response.  I'm still recuperating, and have not remained
on top of my IETF correspondence.

Alan DeKok wrote...

> >   RADIUS could transport parameters for *another* protocol.  Those
> > attributes are not security related.  They either follow the RADIUS data
> > model (int, IP address, etc.), or they are "opaque data" that RADIUS is
> > simply transporting on the behalf of the other protocol.
> 
>   Suggested text in Section A.2.2.:
> 
> A.2.2. Complex Data Types
> 
>    Does the attribute:
> 
>    * define a complex data type
>    * that the RADIUS server and/or client will not treat as opaque data
>      (see Section A.1.3)
>    * for purposes other than authentication or security?
> 
>    If the answers to all of the above items are "yes", this data type
>    SHOULD be replaced
>    with simpler types, as discussed above in Section A.2.1.  Also see
>    Section 2.1.3 for a discussion of why complex types are problematic.

I don't think that the "for purposes other than authentication or security?"
text really addresses the inherent ambiguity.  My understanding is that the
exemption is for authentication or security mechanisms internal to the
RADIUS protocol.  The revised text does not make that "internal to RADIUS"
limitation, and thus remains an open loop-hole, IMO.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 10:51:02 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFCA28C2D0 for ; Tue,  8 Sep 2009 10:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.417
X-Spam-Level: *
X-Spam-Status: No, score=1.417 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFD4VPxuCZO1 for ; Tue,  8 Sep 2009 10:50:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A962828C16D for ; Tue,  8 Sep 2009 10:50:59 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml4o6-000P4w-2F for radiusext-data0@psg.com; Tue, 08 Sep 2009 17:48:42 +0000
Received: from [65.55.111.76] (helo=blu0-omc2-s1.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml4nv-000P1V-5s for radiusext@ops.ietf.org; Tue, 08 Sep 2009 17:48:39 +0000
Received: from BLU137-W2 ([65.55.111.71]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 10:48:30 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_313bde98-40bc-4051-b87d-180d21cb3a5f_"
X-Originating-IP: [166.129.94.173]
From: Bernard Aboba 
To: "David B. Nelson" , Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 10:48:30 -0700
Importance: Normal
In-Reply-To: <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2>
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2>
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 17:48:30.0565 (UTC) FILETIME=[93CCA150:01CA30AC]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_313bde98-40bc-4051-b87d-180d21cb3a5f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> I don't think that the "for purposes other than authentication or securit=
y?"
> text really addresses the inherent ambiguity.  My understanding is that t=
he
> exemption is for authentication or security mechanisms internal to the
> RADIUS protocol.  The revised text does not make that "internal to RADIUS=
"
> limitation=2C and thus remains an open loop-hole=2C IMO.

Appendix B talks about complex attributes.  I'm not sure which of these wou=
ld be considered "internal to RADIUS" and which would not be. =20

For example=2C is Digest Authentication (RFC 5090) internal to RADIUS?  Wha=
t about CHAP?  Or are we talking about Message-Authenticator? =20

IMHO=2C if an attribute doesn't relate to RADIUS=2C but to some external en=
tity=2C then it is effectively opaque and shouldn't be a complex attribute.=
  I think that's what Alan's suggested text says=2C more or less.=20

--_313bde98-40bc-4051-b87d-180d21cb3a5f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







>=3B I don't think that the "for purposes other than authentication o=
r security?"
>=3B text really addresses the inherent ambiguity.  My un=
derstanding is that the
>=3B exemption is for authentication or securi=
ty mechanisms internal to the
>=3B RADIUS protocol.  The revised text =
does not make that "internal to RADIUS"
>=3B limitation=2C and thus re=
mains an open loop-hole=2C IMO.

Appendix B talks about complex attri=
butes. =3B I'm not sure which of these would be considered "internal to=
 RADIUS" and which would not be. =3B 

For example=2C is Digest A=
uthentication (RFC 5090) internal to RADIUS? =3B What about CHAP? =
=3B Or are we talking about Message-Authenticator? =3B 

IMHO=2C =
if an attribute doesn't relate to RADIUS=2C but to some external entity=2C =
then it is effectively opaque and shouldn't be a complex attribute. =3B=
 I think that's what Alan's suggested text says=2C more or less. 

=

--_313bde98-40bc-4051-b87d-180d21cb3a5f_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 10:58:17 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4283A6ADB for ; Tue,  8 Sep 2009 10:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.381
X-Spam-Level: *
X-Spam-Status: No, score=1.381 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z7sqUU6ZZG9 for ; Tue,  8 Sep 2009 10:58:16 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 271813A6AEF for ; Tue,  8 Sep 2009 10:58:16 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml4vm-0002oP-Uz for radiusext-data0@psg.com; Tue, 08 Sep 2009 17:56:38 +0000
Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml4vb-0002h7-6W for radiusext@ops.ietf.org; Tue, 08 Sep 2009 17:56:36 +0000
Received: (qmail 19881 invoked from network); 8 Sep 2009 17:56:25 -0000
Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 8 Sep 2009 17:56:25 -0000
From: "David B. Nelson" 
To: "'Bernard Aboba'" , "'Alan DeKok'" 
Cc: 
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2> 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:56:58 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <417999CAF9B9409F8F67091F96AF38FA@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcowrJxnTAlmj/pmRuOE2CMPMD6PEgAAHfUg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: 
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote...

> IMHO, if an attribute doesn't relate to RADIUS, but to
> some external entity, then it is effectively opaque and
> shouldn't be a complex attribute.

I agree.  My reading of the current, as well as that of others, however, is
that *any* security related attribute, whether in support of the RADIUS
protocol or some external entity, qualifies for an exemption to be designed
as a complex type.  In that regard, "security" attributes for any usage are
covered by this exemption.

> I think that's what Alan's suggested text says, more or less.

It seems to me be way toward the "less".  I think the applicability needs to
be clarified.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 11:20:18 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D853A6818 for ; Tue,  8 Sep 2009 11:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.427
X-Spam-Level: *
X-Spam-Status: No, score=1.427 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AR3BB6D3mzu for ; Tue,  8 Sep 2009 11:20:18 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EADDB3A6812 for ; Tue,  8 Sep 2009 11:20:17 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml5GZ-0007kk-Fw for radiusext-data0@psg.com; Tue, 08 Sep 2009 18:18:07 +0000
Received: from [65.55.111.100] (helo=blu0-omc2-s25.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml5GO-0007jf-Jm for radiusext@ops.ietf.org; Tue, 08 Sep 2009 18:18:04 +0000
Received: from BLU137-W5 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 11:17:55 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_"
X-Originating-IP: [166.129.94.173]
From: Bernard Aboba 
To: "David B. Nelson" , Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 11:17:56 -0700
Importance: Normal
In-Reply-To: <417999CAF9B9409F8F67091F96AF38FA@xpsuperdvd2>
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2>  <417999CAF9B9409F8F67091F96AF38FA@xpsuperdvd2>
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 18:17:55.0996 (UTC) FILETIME=[B01405C0:01CA30B0]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> I agree.  My reading of the current=2C as well as that of others=2C howev=
er=2C is
> that *any* security related attribute=2C whether in support of the RADIUS
> protocol or some external entity=2C qualifies for an exemption to be desi=
gned
> as a complex type.  In that regard=2C "security" attributes for any usage=
 are
> covered by this exemption.

OK.  I would agree that this is too broad. =20

I think the idea was to exempt attributes where *computation* was required =
on the server and client (e.g. Digest Authentication=2C CHAP=2C etc.).   Bu=
t if there is no computation occurring=2C or if the attribute could be cons=
trued as opaque=2C I don't think the exemption is appropriate.=20

For example=2C consider a complex "Security Policy Attribute" sent from ser=
ver to client.  From the server point of view=2C there is no computation in=
volved=2C the server just sends the attribute to the client=2C who is expec=
ted to understand it.  In such a situation=2C there is no intrinsic reason =
why server code changes should be required.  Does such an attribute deserve=
 an exemption?  I would say no.=20

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







>=3B I agree.  My reading of the current=2C as well as that of others=
=2C however=2C is
>=3B that *any* security related attribute=2C whethe=
r in support of the RADIUS
>=3B protocol or some external entity=2C qu=
alifies for an exemption to be designed
>=3B as a complex type.  In th=
at regard=2C "security" attributes for any usage are
>=3B covered by t=
his exemption.

OK. =3B I would agree that this is too broad.&nbs=
p=3B 

I think the idea was to exempt attributes where *computation* =
was required on the server and client (e.g. Digest Authentication=2C CHAP=
=2C etc.). =3B =3B But if there is no computation occurring=2C or i=
f the attribute could be construed as opaque=2C I don't think the exemption=
 is appropriate. 

For example=2C consider a complex "Security Policy=
 Attribute" sent from server to client. =3B From the server point of vi=
ew=2C there is no computation involved=2C the server just sends the attribu=
te to the client=2C who is expected to understand it. =3B In such a sit=
uation=2C there is no intrinsic reason why server code changes should be re=
quired. =3B Does such an attribute deserve an exemption? =3B I woul=
d say no. 

=

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 13:15:58 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EA428C0DE for ; Tue,  8 Sep 2009 13:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.213
X-Spam-Level: 
X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfrjSjn7ytcY for ; Tue,  8 Sep 2009 13:15:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4572E3A69BE for ; Tue,  8 Sep 2009 13:15:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml73A-000M3C-2a for radiusext-data0@psg.com; Tue, 08 Sep 2009 20:12:24 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml72u-000M0y-Q9 for radiusext@ops.ietf.org; Tue, 08 Sep 2009 20:12:21 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 4771212345DC; Tue,  8 Sep 2009 22:12:06 +0200 (CEST)
Message-ID: <4AA6BA94.9020209@deployingradius.com>
Date: Tue, 08 Sep 2009 22:12:04 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: "David B. Nelson" 
CC: radiusext@ops.ietf.org
Subject: Re: Issue 313:  Security Exemption
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2>
In-Reply-To: <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

David B. Nelson wrote:
> I don't think that the "for purposes other than authentication or security?"
> text really addresses the inherent ambiguity.  My understanding is that the
> exemption is for authentication or security mechanisms internal to the
> RADIUS protocol.  The revised text does not make that "internal to RADIUS"
> limitation, and thus remains an open loop-hole, IMO.

  ?

   Does the attribute:

    * define a complex data type
    * that the RADIUS server and/or client will not treat as opaque data
      (see Section A.1.3)

  If the RADIUS server can treat it as opaque data, then it falls under
the purview of A.1.3.  It is permitted, independent of it being used for
authentication, security, or anything else.

  If the RADIUS server has to parse it, then complex attributes are
allowed for authentication and security...

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 13:38:27 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672D228C33E for ; Tue,  8 Sep 2009 13:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSIhN3UHUZ4e for ; Tue,  8 Sep 2009 13:38:26 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DBA23A68A9 for ; Tue,  8 Sep 2009 13:38:26 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml7QS-000Pbh-Lk for radiusext-data0@psg.com; Tue, 08 Sep 2009 20:36:28 +0000
Received: from [65.55.111.113] (helo=blu0-omc2-s38.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml7QG-000Pa3-Rl for radiusext@ops.ietf.org; Tue, 08 Sep 2009 20:36:25 +0000
Received: from BLU137-W31 ([65.55.111.72]) by blu0-omc2-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 13:36:16 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_"
X-Originating-IP: [97.113.1.218]
From: Bernard Aboba 
To: Alan DeKok , "David B. Nelson" 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:36:16 -0700
Importance: Normal
In-Reply-To: <4AA6BA94.9020209@deployingradius.com>
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2> <4AA6BA94.9020209@deployingradius.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2009 20:36:16.0421 (UTC) FILETIME=[03845D50:01CA30C4]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   If the RADIUS server has to parse it=2C then complex attributes are
> allowed for authentication and security...

I think the question is why the exemption should be so broad.  The security=
 and authentication attributes described in Appendix B required computation=
.  That is the RADIUS server had to add code in order to compare the authen=
tication result presented by the RADIUS client with the result it calculate=
d based on its own data.=20

However=2C if the RADIUS server doesn't have to do any computation (e.g. if=
 it is just sending security or authentication-related data to the RADIUS c=
lient)=2C then there is no intrinsic reason why RADIUS server code needs to=
 change.  In that case=2C why should the exemption apply? =20

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B   If the RADIUS server has to parse it=2C then complex attributes ar=
e
>=3B allowed for authentication and security...

I think the q=
uestion is why the exemption should be so broad. =3B The security and a=
uthentication attributes described in Appendix B required computation. =
=3B That is the RADIUS server had to add code in order to compare the authe=
ntication result presented by the RADIUS client with the result it calculat=
ed based on its own data. 

However=2C if the RADIUS server doesn't h=
ave to do any computation (e.g. if it is just sending security or authentic=
ation-related data to the RADIUS client)=2C then there is no intrinsic reas=
on why RADIUS server code needs to change. =3B In that case=2C why shou=
ld the exemption apply? =3B 

=

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 13:39:24 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2D73A69AF for ; Tue,  8 Sep 2009 13:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.192
X-Spam-Level: 
X-Spam-Status: No, score=-100.192 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEI+-ltgsPGt for ; Tue,  8 Sep 2009 13:39:24 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDBEA28C355 for ; Tue,  8 Sep 2009 13:39:23 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml7RA-000PjL-N9 for radiusext-data0@psg.com; Tue, 08 Sep 2009 20:37:12 +0000
Received: from [2001:700:1:2:158:38:152:126] (helo=ufisa.uninett.no) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml7Qs-000Pgp-4B for radiusext@ops.ietf.org; Tue, 08 Sep 2009 20:37:10 +0000
Received: from [128.107.163.68] (dhcp-128-107-163-68.cisco.com [128.107.163.68]) by ufisa.uninett.no (Postfix) with ESMTP id 074923914B for ; Tue,  8 Sep 2009 22:36:52 +0200 (CEST)
Message-ID: <4AA6C062.2000100@venaas.com>
Date: Tue, 08 Sep 2009 13:36:50 -0700
From: Stig Venaas 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> This is a reminder of an ongoing RADEXT WG last call on "RADIUS over 
> TCP", prior to sending this document on to the IESG for publication as 
> an Experimental RFC.  The document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

Looks like my previous email didn't make it. I think the document is
ready, but two minor comments.

1. The draft says:

    RADIUS clients using RADIUS over TCP MUST NOT decide that a
    connection is down until the application layer watchdog algorithm has
    marked it DOWN ([RFC3539] Appendix A).  RADIUS clients using RADIUS
    over TCP MUST NOT decide that a RADIUS server is unresponsive until
    all TCP connections to it have been marked DOWN.

I'm a bit confused by that first sentence. The TCP session might be
reset without the watchdog marking it down. Wouldn't that be sufficient
to say that the connection is down?

2. Should the term RadSec be replaced with RADIUS over TLS?

Stig

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep  8 13:40:51 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B483328C359 for ; Tue,  8 Sep 2009 13:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.199
X-Spam-Level: 
X-Spam-Status: No, score=-100.199 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHAcL9RTCIob for ; Tue,  8 Sep 2009 13:40:50 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BBF128C35A for ; Tue,  8 Sep 2009 13:40:50 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml7SS-000Pvo-Uv for radiusext-data0@psg.com; Tue, 08 Sep 2009 20:38:32 +0000
Received: from [2001:700:1:2:158:38:152:126] (helo=ufisa.uninett.no) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ml7S9-000Psq-Me for radiusext@ops.ietf.org; Tue, 08 Sep 2009 20:38:23 +0000
Received: from [128.107.163.68] (dhcp-128-107-163-68.cisco.com [128.107.163.68]) by ufisa.uninett.no (Postfix) with ESMTP id 9B5D43915E for ; Tue,  8 Sep 2009 22:38:12 +0200 (CEST)
Message-ID: <4AA6C0B2.8040404@venaas.com>
Date: Tue, 08 Sep 2009 13:38:10 -0700
From: Stig Venaas 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> This is a reminder of the ongoing call for review of the document "DTLS 
> as a Transport Layer for RADIUS" for adoption as a RADEXT WG work item.  
> This document is being targeted at Experimental status.
>  
> The document is available for review here:
> http://tools.ietf.org/html/draft-dekok-radext-dtls
> 
> The original call for review expired August 7, 2009, but no comments 
> were received.  This call for input will last until October 2, 2009.  

I'm in favour of adoption,

Stig

> Please send email to the RADEXT WG mailing list indicating whether you 
> support adoption of this document as a RADEXT WG work item.  If you have 
> comments on the document, please also send these to the list in the 
> format described on the RADEXT WG Issues list:
> http://www.drizzle.com/~aboba/RADEXT/ 
> 
> 
> 
> 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 01:03:14 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33C93A6A34 for ; Wed,  9 Sep 2009 01:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.973
X-Spam-Level: 
X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiQlywAGys31 for ; Wed,  9 Sep 2009 01:03:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECD003A697D for ; Wed,  9 Sep 2009 01:03:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlI14-000PqJ-2h for radiusext-data0@psg.com; Wed, 09 Sep 2009 07:54:58 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlI0t-000PpU-JD for radiusext@ops.ietf.org; Wed, 09 Sep 2009 07:54:55 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id A759712345E2; Wed,  9 Sep 2009 09:54:45 +0200 (CEST)
Message-ID: <4AA75F45.6050302@deployingradius.com>
Date: Wed, 09 Sep 2009 09:54:45 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Stig Venaas 
CC: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"
References:  <4AA6C062.2000100@venaas.com>
In-Reply-To: <4AA6C062.2000100@venaas.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Stig Venaas wrote:
> I'm a bit confused by that first sentence. The TCP session might be
> reset without the watchdog marking it down. Wouldn't that be sufficient
> to say that the connection is down?

  Yes.

> 2. Should the term RadSec be replaced with RADIUS over TLS?

  Yes.  The decision to remove the RadSec name was made after the draft
had been submitted.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 01:43:01 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DEE3A67D8 for ; Wed,  9 Sep 2009 01:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.393
X-Spam-Level: 
X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtGYjr5lC1Ez for ; Wed,  9 Sep 2009 01:42:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE5C53A67B2 for ; Wed,  9 Sep 2009 01:42:59 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlIjX-0004OV-NG for radiusext-data0@psg.com; Wed, 09 Sep 2009 08:40:55 +0000
Received: from [198.152.12.100] (helo=nj300815-nj-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlIjC-0004KM-Th for radiusext@ops.ietf.org; Wed, 09 Sep 2009 08:40:50 +0000
X-IronPort-AV: E=Sophos;i="4.44,357,1249272000";  d="scan'208";a="172763987"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 09 Sep 2009 04:40:27 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Sep 2009 04:40:25 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 10:40:24 +0200
Message-ID: 
In-Reply-To: <200909081535.n88FZL4e026640@boreas.isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Technical Errata Reported] RFC4282 (1848)
thread-index: AcowmiKV2b2xb7C7RyaLek8HYvzrNwAjlsqg
References: <200909081535.n88FZL4e026640@boreas.isi.edu>
From: "Romascanu, Dan (Dan)" 
To: "RFC Errata System" , , , , , , , 
Cc: , 
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

> Much of RFC 4282 is simply wrong.=20

If this is the case, I do not believe that an Errata is the right
instrument to fix the situation, but rather the WG working on a document
to obsolete and replace RFC 4282 or simply declare it Historical.=20

I would invite other opinions from the WG and especially from the
editors.=20

Thanks and Regards,

Dan


> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20
> Sent: Tuesday, September 08, 2009 6:35 PM
> To: bernarda@microsoft.com; mbeadles@endforce.com;=20
> jari.arkko@ericsson.com; pasi.eronen@nokia.com; Romascanu,=20
> Dan (Dan); rbonica@juniper.net; d.b.nelson@comcast.net;=20
> Bernard_Aboba@hotmail.com
> Cc: aland@freeradius.org; radiusext@ops.ietf.org;=20
> rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC4282 (1848)
>=20
>=20
> The following errata report has been submitted for RFC4282,=20
> "The Network Access Identifier".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4282&eid=3D1848
>=20
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok 
>=20
> Section: 2.4
>=20
> Original Text
> -------------
>    o  Normalization requirements, as specified in Section 2.2 of
>       [RFC4013], are also designed to assist in comparisons.
>=20
> Corrected Text
> --------------
>   o Normalization is, in general, a bad idea.
>=20
> Notes
> -----
> Much of RFC 4282 is simply wrong.
>=20
> Normalization can be done only when both the local and=20
> character set information is included with the text.  And=20
> that information is not included with the username or realm.
>=20
> In addition, not all systems will treat "User" the same as=20
> "user".  The decision about how to compare user names is site=20
> specific.  User name comparisons SHOULD NOT be performed on=20
> any system other than the final one that performs user authentication.
>=20
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,=20
> please use "Reply All" to discuss whether it should be=20
> verified or rejected. When a decision is reached, the=20
> verifying party (IESG) can log in to change the status and=20
> edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC4282 (draft-ietf-radext-rfc2486bis-06)
> --------------------------------------
> Title               : The Network Access Identifier
> Publication Date    : December 2005
> Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
> Category            : PROPOSED STANDARD
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 02:32:58 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C52F28C0EF for ; Wed,  9 Sep 2009 02:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhPQTOtxs-AO for ; Wed,  9 Sep 2009 02:32:57 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 777653A6A94 for ; Wed,  9 Sep 2009 02:32:57 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlJW8-000Abf-9r for radiusext-data0@psg.com; Wed, 09 Sep 2009 09:31:08 +0000
Received: from [76.96.59.243] (helo=QMTA13.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlJVx-000Aav-OQ for radiusext@ops.ietf.org; Wed, 09 Sep 2009 09:31:06 +0000
Received: from OMTA22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA13.westchester.pa.mail.comcast.net with comcast id eZWY1c0011ap0As5DZWxlA; Wed, 09 Sep 2009 09:30:57 +0000
Received: from gwzPC ([87.24.177.55]) by OMTA22.westchester.pa.mail.comcast.net with comcast id eZZX1c0081C5iVj3iZZcTo; Wed, 09 Sep 2009 09:34:20 +0000
From: "Glen Zorn" 
To: "'Romascanu, Dan \(Dan\)'" , , , , , , , 
Cc: , 
References: <200909081535.n88FZL4e026640@boreas.isi.edu> 
In-Reply-To: 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 11:29:59 +0200
Message-ID: <001501ca3130$371b7ce0$a55276a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcowmiKV2b2xb7C7RyaLek8HYvzrNwAjlsqgAAGzD7A=
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Dan Romascanu [mailto://dromasca@avaya.com] writes:

> > Much of RFC 4282 is simply wrong.
> 
> If this is the case, I do not believe that an Errata is the right
> instrument to fix the situation, but rather the WG working on a
> document
> to obsolete and replace RFC 4282 or simply declare it Historical.
> 
> I would invite other opinions from the WG and especially from the
> editors.

Not that I want to question (God forbid!) the godlike opinion of Alan DeKok,
but could we have just a smidgeon of justification for that statement before
tossing RFC 4282?

...


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 03:27:46 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60FB13A692F for ; Wed,  9 Sep 2009 03:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQF4tkJMh0VV for ; Wed,  9 Sep 2009 03:27:45 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FBE03A67E9 for ; Wed,  9 Sep 2009 03:27:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlKMX-000GmC-37 for radiusext-data0@psg.com; Wed, 09 Sep 2009 10:25:17 +0000
Received: from [76.96.59.211] (helo=QMTA11.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlKML-000Gka-95 for radiusext@ops.ietf.org; Wed, 09 Sep 2009 10:25:14 +0000
Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id eaPf1c0061GhbT85BaR55c; Wed, 09 Sep 2009 10:25:05 +0000
Received: from gwzPC ([87.24.177.55]) by OMTA07.westchester.pa.mail.comcast.net with comcast id eaQM1c00E1C5iVj3TaQTZy; Wed, 09 Sep 2009 10:25:03 +0000
From: "Glen Zorn" 
To: 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , , 
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org>
In-Reply-To: <4AA77B10.9030209@freeradius.org>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 12:24:15 +0200
Message-ID: <002401ca3137$c375a5b0$4a60f110$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoxM2AqslUD/MQeRDu0aUO3Fbb8iQAA+ZkQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan T DeKok [mailto:aland@freeradius.org] writes:

> Glen Zorn wrote:
> > Not that I want to question (God forbid!) the godlike opinion of Alan
> DeKok,
> > but could we have just a smidgeon of justification for that statement
> before
> > tossing RFC 4282?
> 
>   Perhaps you would appreciate my comments more if I noted that:
> 
> a) the i18n work in 4282 has been deprecated, found to be faulty, or
>    replaced, by later i18n documents
> 
> b) nearly all of the rest of the recommendations in 4282 have been
>    ignored (and not implemented) by all of the AAA vendors
> 
> c) I was not involved in any of the i18n work that negated the
>    recommendations of 4282
> 
> d) no major AAA vendor has ever asked for my opinion on how to
>    implement 4282 in their product.
> 
> 
>   Don't blame the messenger.
> 
>   If you have a problem with the statement that 4282 is wrong, go fight
> with the i18n people.  Once you've done that, go force all of the AAA
> vendors to implement the other recommendations of 4282.
> 
>   Or, you can attack me for pointing out the problems.  Which is
> easier?

"it's wrong" hardly qualifies as "pointing out the problems".  OTOH, this
message (was it so hard?) may.

> 
> 
>   This subject was discussed last year on the on RADEXT list.  See
> message subjects with 4282 in them.  I don't see you having any
> comments
> at that time.  I also see a number of comments from other people who
> also claim to see problems with 4282.
> 
> 
>   At a minimum:
> 
> - the mapping requirements are likely wrong.  Intermediate nodes
>   should not be doing comparisons on the username portion of an NAI.
> 
> - the bidirectional rules are superseded by later BIDI documents
> 
> - the suggestion to reject NAIs with unassigned code points
>   means that those code points can never be assigned, as conformant
>   implementations that have not yet been updated will reject those
> NAIs.
> 
> - the suggestion to encode NAIs as punycode is implemented by no one.
> 
> - the suggest for intermediate nodes to normalize the NAI is
>   unnecessary, can cause inter-operability requirements, and is
>   implemented by no one.
> 
> 
>   Again, these are not *my* points.  I'm just repeating comments from
> *other* people on the RADEXT mailing list.
> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 05:59:04 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E8228C1F2 for ; Wed,  9 Sep 2009 05:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqcxvcgiq-y5 for ; Wed,  9 Sep 2009 05:59:04 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBC3A28C164 for ; Wed,  9 Sep 2009 05:59:03 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlMhR-000CZj-Tu for radiusext-data0@psg.com; Wed, 09 Sep 2009 12:55:01 +0000
Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlMhQ-000CZF-49 for radiusext@ops.ietf.org; Wed, 09 Sep 2009 12:55:01 +0000
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA09.westchester.pa.mail.comcast.net with comcast id ebev1c0030SCNGk59cuzm1; Wed, 09 Sep 2009 12:54:59 +0000
Received: from gwzPC ([87.24.177.55]) by OMTA09.westchester.pa.mail.comcast.net with comcast id ecuQ1c00G1C5iVj3VcuUeH; Wed, 09 Sep 2009 12:54:57 +0000
From: "Glen Zorn" 
To: 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , , 
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <002401ca3137$c375a5b0$4a60f110$@net> <4AA79B5D.7000608@freeradius.org>
In-Reply-To: <4AA79B5D.7000608@freeradius.org>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 14:54:18 +0200
Message-ID: <004001ca314c$b85c4250$2914c6f0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoxRqBHLbN/CTa0TQiwrtyXTPaPNgAA9f7A
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan T DeKok [mailto:aland@freeradius.org] writes:

> Glen Zorn wrote:
> > "it's wrong" hardly qualifies as "pointing out the problems".  OTOH,
> this
> > message (was it so hard?) may.
> 
>   The errata I filed had explanations as to what was wrong, why it was
> wrong, and suggested replacement text.
> 
>   You picked *one* sentence out of 20, ignored the rest, ignored the
> previous mailing list discussion, and then claimed (essentially) that I
> had no justification for seeing problems with 4282.
> 
>   Could you please read my messages before attacking me?

Terribly unfair of me.  To redress this wrong, I have reproduced the erratum
in question in full below:

Errata ID: 1848

Status: Reported
Type: Technical

Reported By: Alan DeKok
Date Reported: 2009-09-08


Section 2.4 says: 

   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

It should say:

  o Normalization is, in general, a bad idea.
Notes:

Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set
information is included with the text. And that information is not included
with the username or realm.

In addition, not all systems will treat "User" the same as "user". The
decision about how to
compare user names is site specific. User name comparisons SHOULD NOT be
performed on
any system other than the final one that performs user authentication. 


I count 8 sentences (including the one reproduced from the RFC), not 20.
One of those sentences appears to be irrelevant hyperbole ("Much of RFC 4282
is simply wrong.") & another is incomprehensible (what does "Normalization
can be done only when both the local and character set information is
included with the text." mean?  Did you mean "locale"?  Why should we have
to guess?).  Based upon this evidence, I have no choice but to conclude that
you are absolutely right: RFC 4282 should be trashed immediately (apparently
the same conclusion reached by the IESG, based upon the same evidence).

> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 06:03:02 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586A728C485 for ; Wed,  9 Sep 2009 06:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKUzTDpSeBZz for ; Wed,  9 Sep 2009 06:03:01 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44CAF28C455 for ; Wed,  9 Sep 2009 06:03:01 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlMn8-000E6L-Sv for radiusext-data0@psg.com; Wed, 09 Sep 2009 13:00:54 +0000
Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlMn6-000E5f-Oz for radiusext@ops.ietf.org; Wed, 09 Sep 2009 13:00:53 +0000
Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA01.westchester.pa.mail.comcast.net with comcast id eb8W1c0020ldTLk51d0tac; Wed, 09 Sep 2009 13:00:53 +0000
Received: from gwzPC ([87.24.177.55]) by OMTA04.westchester.pa.mail.comcast.net with comcast id ed031c00J1C5iVj3Qd09ds; Wed, 09 Sep 2009 13:00:51 +0000
From: "Glen Zorn" 
To: "'Jari Arkko'" , 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , 
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <4AA782F2.3000908@ericsson.com> <4AA79A9B.4000104@freeradius.org> <4AA79E3A.9010401@ericsson.com>
In-Reply-To: <4AA79E3A.9010401@ericsson.com>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 14:59:57 +0200
Message-ID: <004701ca314d$8a927fa0$9fb77ee0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoxSFXHiXKy+/+MRyK5Kp6mbwzlywABGREA
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Jari Arkko [mailto:jari.arkko@ericsson.com] writes:

> Alan,
> 
> >   It would be good to note at least that the document should be
> largely
> > ignored.  Errata may be a good way to do this.
> >
> 
> I do not believe errata is the right way to do this. 

Why not?  My understanding is that accepted technical errata are generally
saved up & incorporated in a new RFC.  Is that incorrect?  If not, why isn't
that the way to deal with this particular case?

> Furthermore, 4282
> contains more updates than the i18n parts.
> 
> >   There was some discussion last year about working on an update to
> > 4282.  There didn't seem to be much interest, unfortunately.  Maybe
> if
> > we can get the 4-5 pending RADEXT documents out of the way, there may
> be
> > interest in working on updates to 4282.
> >
> 
> That is the best way, IMO. 

Since 4282 wasn't the product of either the radext or radius WGs, what makes
radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
Chair.

> We also need to analyze the problem and
> possible solutions in detail. I confess that I have not looked at the
> issues, so I can offer no comment on them yet.
> 
> Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 06:25:47 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F96E3A6C1A for ; Wed,  9 Sep 2009 06:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW-bjXr1nPFq for ; Wed,  9 Sep 2009 06:25:46 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13BDB3A6C12 for ; Wed,  9 Sep 2009 06:25:46 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlN95-000I5H-EM for radiusext-data0@psg.com; Wed, 09 Sep 2009 13:23:35 +0000
Received: from [76.96.30.64] (helo=QMTA07.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlN93-000I4z-VR for radiusext@ops.ietf.org; Wed, 09 Sep 2009 13:23:34 +0000
Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id ec8l1c0090vp7WLA7dPaWq; Wed, 09 Sep 2009 13:23:34 +0000
Received: from gwzPC ([87.24.177.55]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id edP21c0011C5iVj8RdP5W7; Wed, 09 Sep 2009 13:23:32 +0000
From: "Glen Zorn" 
To: 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , , 
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <002401ca3137$c375a5b0$4a60f110$@net> <4AA79B5D.7000608@freeradius.org> <004001ca314c$b85c4250$2914c6f0$@net> <4AA7AA22.10100@freeradius.org>
In-Reply-To: <4AA7AA22.10100@freeradius.org>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 15:22:56 +0200
Message-ID: <005c01ca3150$b6e89140$24b9b3c0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoxT21V4jOsQe+ITM+/iKEIe1rJdwAAMofQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan T DeKok [mailto:aland@freeradius.org] writes:

> Glen Zorn wrote:
> > I count 8 sentences (including the one reproduced from the RFC), not
> 20.
> 
>   Please check your inbox.  There were other errata filed at the same
> time, with additional explanatory text.

I didn't respond to those.  How are they relevant?

> 
> > One of those sentences appears to be irrelevant hyperbole ("Much of
> RFC 4282
> > is simply wrong.") & another is incomprehensible (what does
> "Normalization
> > can be done only when both the local and character set information is
> > included with the text." mean?  Did you mean "locale"?  Why should we
> have
> > to guess?).  Based upon this evidence, I have no choice but to
> conclude that
> > you are absolutely right: RFC 4282 should be trashed immediately
> (apparently
> > the same conclusion reached by the IESG, based upon the same
> evidence).
> 
>   As I said, please check the RADEXT archives for longer discussions
> about this issue.  That discussion includes comments from other people
> explaining what is wrong with 4282.

Alan, you filed an Errata with the RFC Editor.  Do you expect them to search
the radext archives?

> 
>   Maybe one of those people can talk to you without you claiming that
> they have a god complex.  I know I can't.

For DeKok's sake, quit your whining! ;-)

> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 06:26:54 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDB73A6C27 for ; Wed,  9 Sep 2009 06:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.661
X-Spam-Level: 
X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBa1DP4cckd2 for ; Wed,  9 Sep 2009 06:26:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D4EC3A6C25 for ; Wed,  9 Sep 2009 06:26:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlNBA-000IU0-Oa for radiusext-data0@psg.com; Wed, 09 Sep 2009 13:25:44 +0000
Received: from [2001:14b8:400::130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlNB8-000ISo-Vh for radiusext@ops.ietf.org; Wed, 09 Sep 2009 13:25:43 +0000
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3CBD4D632A; Wed,  9 Sep 2009 16:25:42 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cEHG0qEmJoD; Wed,  9 Sep 2009 16:25:41 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6C9FDD6258; Wed,  9 Sep 2009 16:25:41 +0300 (EEST)
Message-ID: <4AA7ACD4.8010204@piuha.net>
Date: Wed, 09 Sep 2009 16:25:40 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Glen Zorn 
CC: aland@freeradius.org, "'Romascanu, Dan \(Dan\)'" ,  bernarda@microsoft.com, mbeadles@endforce.com, pasi.eronen@nokia.com,  rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <4AA782F2.3000908@ericsson.com> <4AA79A9B.4000104@freeradius.org> <4AA79E3A.9010401@ericsson.com> <004701ca314d$8a927fa0$9fb77ee0$@net>
In-Reply-To: <004701ca314d$8a927fa0$9fb77ee0$@net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen,

> Why not?  My understanding is that accepted technical errata are generally
> saved up & incorporated in a new RFC.  Is that incorrect?  If not, why isn't
> that the way to deal with this particular case?
>   

Erratas are for correcting small problems. If you have to rewrite large 
parts, that requires significant effort, review, and a proper new document.

> Since 4282 wasn't the product of either the radext or radius WGs, what makes
> radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
> Chair.
>   
4282 was a product of the RADEXT WG.

In any case, I would suggest we stop talking about process or other non 
essential stuff. If the 4282 i18n text is not correct, is there some 
other text that would work, Alan?

Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 06:54:25 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39E528C4A3 for ; Wed,  9 Sep 2009 06:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy2WVWez827Y for ; Wed,  9 Sep 2009 06:54:25 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C85A23A6976 for ; Wed,  9 Sep 2009 06:54:24 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlNai-000MNM-Jr for radiusext-data0@psg.com; Wed, 09 Sep 2009 13:52:08 +0000
Received: from [76.96.62.24] (helo=QMTA02.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlNag-000MN1-Gl for radiusext@ops.ietf.org; Wed, 09 Sep 2009 13:52:07 +0000
Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA02.westchester.pa.mail.comcast.net with comcast id eblF1c0060Fqzac52ds6L7; Wed, 09 Sep 2009 13:52:06 +0000
Received: from gwzPC ([87.24.177.55]) by OMTA08.westchester.pa.mail.comcast.net with comcast id edrY1c00c1C5iVj3UdrbB7; Wed, 09 Sep 2009 13:52:04 +0000
From: "Glen Zorn" 
To: "'Jari Arkko'" 
Cc: , "'Romascanu, Dan \(Dan\)'" , , , , , , , 
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <4AA782F2.3000908@ericsson.com> <4AA79A9B.4000104@freeradius.org> <4AA79E3A.9010401@ericsson.com> <004701ca314d$8a927fa0$9fb77ee0$@net> <4AA7ACD4.8010204@piuha.net>
In-Reply-To: <4AA7ACD4.8010204@piuha.net>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 15:51:26 +0200
Message-ID: <006601ca3154$b2cd66e0$186834a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoxUQwvQ2aZ1ncAQGyo+KH/DoDNjQAAwtlQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Jari Arkko [mailto:jari.arkko@piuha.net] writes:

> Glen,
> 
> > Why not?  My understanding is that accepted technical errata are
> generally
> > saved up & incorporated in a new RFC.  Is that incorrect?  If not,
> why isn't
> > that the way to deal with this particular case?
> >
> 
> Erratas are for correcting small problems. If you have to rewrite large
> parts, that requires significant effort, review, and a proper new
> document.
> 
> > Since 4282 wasn't the product of either the radext or radius WGs,
> what makes
> > radext the right place to do it?  I'd suggest a new WG, with Alan
> DeKok as a
> > Chair.
> >
> 4282 was a product of the RADEXT WG.

You're absolutely right; I was thinking of RFC 2486, which it obsolete.  The
point remains the same, however: changes to 4282 don't just effect RADIUS,
but Diameter, possibly EAP and a number of standards published by other
SDOs.

> 
> In any case, I would suggest we stop talking about process or other non
> essential stuff. If the 4282 i18n text is not correct, is there some
> other text that would work, Alan?
> 
> Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 07:05:43 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D5728C48A for ; Wed,  9 Sep 2009 07:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.132
X-Spam-Level: 
X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MSGID_MULTIPLE_AT=1.449, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-IbIKb7lbUS for ; Wed,  9 Sep 2009 07:05:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E538D28C161 for ; Wed,  9 Sep 2009 07:05:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlNkU-000Nek-Hn for radiusext-data0@psg.com; Wed, 09 Sep 2009 14:02:14 +0000
Received: from [74.208.4.195] (helo=mout.perfora.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlNkT-000NeU-Ep for radiusext@ops.ietf.org; Wed, 09 Sep 2009 14:02:13 +0000
Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MlNjq0sVf-000imp; Wed, 09 Sep 2009 10:01:50 -0400
From: "Alper Yegin" 
To: "'Glen Zorn'" , "'Jari Arkko'" 
Cc: , "'Romascanu, Dan \(Dan\)'" , , , , , , , 
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <4AA782F2.3000908@ericsson.com> <4AA79A9B.4000104@freeradius.org> <4AA79E3A.9010401@ericsson.com> <004701ca314d$8a927fa0$9fb77ee0$@net> <4AA7ACD4.8010204@piuha.net> <006601ca3154$b2cd66e0$186834a0$@net>
In-Reply-To: <006601ca3154$b2cd66e0$186834a0$@net>
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 17:01:30 +0300
Message-ID: <005a01ca3156$12d7c700$38875500$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcoxUQwvQ2aZ1ncAQGyo+KH/DoDNjQAAwtlQAABvE1A=
Content-Language: en-us
X-Provags-ID: V01U2FsdGVkX18RJWPBa8dX0P6diq2TMSWNsnoqmesmFAdVPga dOmp0/PSCJ8Dv/OqsyDp6lX58MAzbPB8UTMEhukifb7VV2i/pn LgnE9GHIPLYPKaAaDET9g==
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

> You're absolutely right; I was thinking of RFC 2486, which it obsolete.
> The
> point remains the same, however: changes to 4282 don't just effect
> RADIUS,
> but Diameter, possibly EAP and 

+ Mobile IP family of protocols....


> a number of standards published by other
> SDOs.

Indeed.

What is the take on backward compatibility?

Alper





> 
> >
> > In any case, I would suggest we stop talking about process or other
> non
> > essential stuff. If the 4282 i18n text is not correct, is there some
> > other text that would work, Alan?
> >
> > Jari
> 
> 
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 09:21:14 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D5E3A69CE for ; Wed,  9 Sep 2009 09:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.66
X-Spam-Level: 
X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEDY6q19Ao9u for ; Wed,  9 Sep 2009 09:21:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 891BE3A6999 for ; Wed,  9 Sep 2009 09:21:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlPsg-000Gbt-8J for radiusext-data0@psg.com; Wed, 09 Sep 2009 16:18:50 +0000
Received: from [2001:14b8:400::130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlPse-000GbP-Mj for radiusext@ops.ietf.org; Wed, 09 Sep 2009 16:18:49 +0000
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 81222D6330; Wed,  9 Sep 2009 19:18:46 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV3P+NH5VeiT; Wed,  9 Sep 2009 19:18:46 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B842ED6268; Wed,  9 Sep 2009 19:18:45 +0300 (EEST)
Message-ID: <4AA7D564.6050803@piuha.net>
Date: Wed, 09 Sep 2009 19:18:44 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: aland@freeradius.org
CC: Glen Zorn ,  "'Romascanu, Dan \(Dan\)'" , bernarda@microsoft.com, mbeadles@endforce.com, pasi.eronen@nokia.com,  rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <4AA782F2.3000908@ericsson.com> <4AA79A9B.4000104@freeradius.org> <4AA79E3A.9010401@ericsson.com> <004701ca314d$8a927fa0$9fb77ee0$@net> <4AA7ACD4.8010204@piuha.net> <4AA7B9B4.2010405@freeradius.org>
In-Reply-To: <4AA7B9B4.2010405@freeradius.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Excellent -- I will review this. For the benefit of others, here's a diff:

http://tools.ietf.org/rfcdiff?url1=rfc4282.txt&url2=draft-dekok-radext-nai-00.txt

(and to the original RFC: 
http://tools.ietf.org/rfcdiff?url1=rfc2486.txt&url2=draft-dekok-radext-nai-00.txt)

Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 10:05:36 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A516728C102 for ; Wed,  9 Sep 2009 10:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.66
X-Spam-Level: 
X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3TEUlka7gPq for ; Wed,  9 Sep 2009 10:05:35 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5684F3A6765 for ; Wed,  9 Sep 2009 10:05:31 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlQYR-000P4V-Go for radiusext-data0@psg.com; Wed, 09 Sep 2009 17:01:59 +0000
Received: from [2001:14b8:400::130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlQYP-000P3z-2Q for radiusext@ops.ietf.org; Wed, 09 Sep 2009 17:01:58 +0000
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8CFC8D6331; Wed,  9 Sep 2009 20:01:55 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LShcVCjgiXsG; Wed,  9 Sep 2009 20:01:54 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 76C0DD6268; Wed,  9 Sep 2009 20:01:54 +0300 (EEST)
Message-ID: <4AA7DF81.2010609@piuha.net>
Date: Wed, 09 Sep 2009 20:01:53 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: aland@freeradius.org
CC: Alper Yegin ,  'Glen Zorn' , "'Romascanu, Dan \(Dan\)'" , bernarda@microsoft.com,  mbeadles@endforce.com, pasi.eronen@nokia.com, rbonica@juniper.net,  d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <4AA782F2.3000908@ericsson.com> <4AA79A9B.4000104@freeradius.org> <4AA79E3A.9010401@ericsson.com> <004701ca314d$8a927fa0$9fb77ee0$@net> <4AA7ACD4.8010204@piuha.net> <006601ca3154$b2cd66e0$186834a0$@net> <005a01ca3156$12d7c700$38875500$@yegin@yegin.org> <4AA7BA69.7070701@freeradius.org>
In-Reply-To: <4AA7BA69.7070701@freeradius.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Thanks again for writing this up.

Some initial comments:

Overall I liked it, but there are of course of number of things to 
discuss...

Section 1.2 boilerplate is not according to RFC 2119.

grammer => grammar

> o Section 2.1 did not contain ABNF for the UTF-8 form of the   
>             realm. This makes it impossible to create an 
> inter-operable   
>             internationalized version of the realm

But the realm was not specified to carry UTF-8. As the RFC said later:

   The realm name is an "IDN-unaware domain name slot" as defined in
   [RFC3490].  That is, it can contain only ASCII characters.  An
   implementation MAY support Internationalized Domain Names (IDNs)
   using the ToASCII operation; see [RFC3490] for more information.

I realize that there may be other reasons -- such as compatibility with 
EAP RFCs that demands plain UTF-8 should be used. However, the argument 
above does not seem correct.

> o Section 2.5 required mappings that are language-specific,   
>             and which are nearly impossible to perform correctly 
> without   
>             information about that language.

I guess this means Section 2.4 of RFC 4282, right?

Also, the mappings required in that section are to be done by the end 
systems where the user types in the strings. Such end systems can be 
aware of what character set and language the user employs. I agree that 
none of the intermediate systems could have any idea about that, but 
AFAICT that was not required by the RFC.

>  normalization form NFC for NAIs is REQUIRED.
Expand NFC

> The grammar for   
>     the username is based on [RFC0821], and the grammar for the realm 
> is        the user and realm portion is based on a combination of the 
> "nai"   
>     an updated version of [RFC1035].        defined in [RFC4282] 
> Section 2.1, and the "utf8-addr-spec" defined in   
>             [RFC5335] Section 4.4.
I was confused by this statement. Do you mean that you normatively refer 
4282 for these definitions or that this is how you arrived at the ABNF? 
I think you should just say "this is the ABNF" and if there's any 
rationale that needs to be said, add it to Section 1.4.

> .fi

Nroff problem...

> in question. Therefore, the username portion SHOULD be treated as

Since you changed the ABNF names, this probably should now be 
utf8-username to be exact what you mean by the username portion.

> In order to ensure a canonical representation

I would like to understand this better. 4282 provided canonicalization 
in order to make sure that when you look up a username db lookups and 
routing table comparisons work. Does the bis have the same property, and 
how so?

>    In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
>    systems to perform NAI comparisons, matching, and AAA routing based
>    on the NAI as it is received.  This requirement provides a canonical
>    representation, ensures that intermediate systems such as AAA proxies
>    do not need to perform translations, and can be expected to work
>    through systems that are unaware of international character sets.

I though that this was the case already with RFC 4282, but maybe I'm 
missing something.

> For example, much of the common realm routing can be done on the   
>             "utf8-realm" portion of NAI, through simple checks for 
> equality.

I thought that suffix match was also a possibility in some systems.

> 2.7. Routing inside of AAA Systems
Good stuff.

> There are, however, a number of problems with this approach. A AAA   
>             proxy may not have sufficient information in order to 
> perform the   
>             ToAscii conversion properly. We therefore RECOMMEND that 
> only the   
>             owner of the realm perform the ToAscii conversion. We 
> RECOMMEND that   
>             the owner of the realm pre-provision to all proxies the 
> "utf8-realm"   
>             portion of the NAI, along with the canonical form returned 
> by the   
>             ToAscii function. This canonical form can then be used in 
> the   
>             logical AAA routing table discussed above, in order to 
> perform DNS   
>             lookups

And here's the tradeoff for using UTF-8 as opposed to IDN unaware name 
slots. I was trying to think about situations where the DNS lookups are 
needed and whether they'd form a problem. Can you name a few of the 
situations where DNS name lookups from NAIs are actually used today?

> 2.10.1. Historical Practices
I'm personally not very fond of the decoration practices, but they do 
exist. I think we need a discussion before those can be removed from the 
RFC.

Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep  9 10:47:01 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F63928C1CE for ; Wed,  9 Sep 2009 10:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu7mPIp716Jd for ; Wed,  9 Sep 2009 10:46:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C02D28C286 for ; Wed,  9 Sep 2009 10:46:59 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlRE8-0007Et-Ui for radiusext-data0@psg.com; Wed, 09 Sep 2009 17:45:04 +0000
Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlRDy-0007Cg-1I for radiusext@ops.ietf.org; Wed, 09 Sep 2009 17:44:56 +0000
Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id eh5J1c0070x6nqcA5hkuSe; Wed, 09 Sep 2009 17:44:54 +0000
Received: from gwzPC ([79.14.208.174]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id ehkG1c00g3mJ6Jv8YhkL5z; Wed, 09 Sep 2009 17:44:52 +0000
From: "Glen Zorn" 
To: , , , , , , , 
Cc: , 
References: <200909081538.n88Fcqfs027959@boreas.isi.edu>
In-Reply-To: <200909081538.n88Fcqfs027959@boreas.isi.edu>
Subject: RE: [Technical Errata Reported] RFC4282 (1850)
Date: Wed, 9 Sep 2009 19:44:07 +0200
Message-ID: <004501ca3175$387ea900$a97bfb00$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcowmzYlv1u8ZfpHQiG//1rrlLOUhAA2Nh3w
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

I thought about writing a long response to this, referencing RFCs 3454 &
4013 and the Unicode 3.2 standard but in the end decided that the use of
logic and analysis would be a total waste of time.  So I'll just say that
this Errata makes no sense at all & let it go at that.  To understand why
it's nonsense, you'll have to do your own research.

> The following errata report has been submitted for RFC4282,
> "The Network Access Identifier".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1850
> 
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok 
> 
> Section: 2.4
> 
> Original Text
> -------------
>    o  Unassigned code points are specified in Section 2.5 of [RFC4013].
>       The use of unassigned code points is prohibited.
> 
> Corrected Text
> --------------
>   o Unassigned code points MUST be ignored
> 
> Notes
> -----
> Unassigned code points sometimes go through a process called
> "assignment".  This means that they suddenly become valid.
> 
> Implementations that forbid unassigned code points will not be updated
> when the standards change to assign them.  Therefore, they should
> ignore unassigned code points.
> 
> Happily, this is what all implementations do.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC4282 (draft-ietf-radext-rfc2486bis-06)
> --------------------------------------
> Title               : The Network Access Identifier
> Publication Date    : December 2005
> Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
> Category            : PROPOSED STANDARD
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 10 02:13:28 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6F43A6A08 for ; Thu, 10 Sep 2009 02:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c6+z4ziDO0n for ; Thu, 10 Sep 2009 02:13:27 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 110C63A6A09 for ; Thu, 10 Sep 2009 02:13:27 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlfdB-000Etv-E5 for radiusext-data0@psg.com; Thu, 10 Sep 2009 09:07:53 +0000
Received: from [76.96.62.17] (helo=QMTA10.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mlfd7-000EtX-AC for radiusext@ops.ietf.org; Thu, 10 Sep 2009 09:07:52 +0000
Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA10.westchester.pa.mail.comcast.net with comcast id ex301c0050xGWP85Ax7o3x; Thu, 10 Sep 2009 09:07:48 +0000
Received: from gwzPC ([87.24.177.55]) by OMTA12.westchester.pa.mail.comcast.net with comcast id ex7T1c00C1C5iVj3Yx7Ya9; Thu, 10 Sep 2009 09:07:46 +0000
From: "Glen Zorn" 
To: "'Jari Arkko'" 
Cc: , "Paul Hoffman" , "Harald Tveit Alvestrand" 
References: <200909081538.n88Fcqfs027959@boreas.isi.edu> <004501ca3175$387ea900$a97bfb00$@net> <4AA7EA93.8040504@piuha.net>
In-Reply-To: <4AA7EA93.8040504@piuha.net>
Subject: RE: [Technical Errata Reported] RFC4282 (1850)
Date: Thu, 10 Sep 2009 11:07:18 +0200
Message-ID: <000001ca31f6$264396c0$72cac440$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoxddlL2UqxC0XlQH2l0xRSN5oA7gAdDGeg
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Jari Arkko [mailto:jari.arkko@piuha.net] writes:

> Glen Zorn wrote:
> > I thought about writing a long response to this, referencing RFCs
> 3454 &
> > 4013 and the Unicode 3.2 standard but in the end decided that the use
> of
> > logic and analysis would be a total waste of time.  So I'll just say
> that
> > this Errata makes no sense at all & let it go at that.  To understand
> why
> > it's nonsense, you'll have to do your own research.
> >
> >
> 
> Humor me

If you insist...

> Apparently I don't understand i18n as well as the rest of you do :-)

I absolutely not an expert on internationalization (though I confess to
having conversed occasionally with Paul Hoffman & Harald Alvestrand, who are
veritable founts of knowledge on the subject -- hopefully if I get any of
this wrong one of them can save us from my ignorance): the last work I did
on it was for L2TPv3 more than 4 years ago.  Fortunately, however, no such
expertise is really needed, aside from the abilities to read and reason.
The reference in the original text to which the erratum refers is to section
2.5 of RFC 4013, but that just points to Appendix A.1 of RFC 3454.  Appendix
A.1 is just a list of the unassigned code points in Unicode 3.2.  There is
no mechanism specified in 3454 for assigning code points (via IANA, for
example); that's because code points are assigned in the Unicode standard.
That should be enough: the list of unassigned code points is in an RFC
which, by definition, will never change.  If, however, one possessed a
little bit of knowledge about Unicode (say, from spending 20-30 minutes
looking around http://www.unicode.org) one could discover that the assigned
and unassigned code points are part of the Unicode repertoire for a given
major or minor version of the standard.  This means that section A.1 of RFC
3454 defines forever the set of unassigned code points: unassigned code
points may be assigned but not in v3.2.  I hope it's clear from this
discussion that talking about "unassigned code points" w/o reference to a
stringprep profile or Unicode version is meaningless.  The "old text" was
correct and precise, including a stable reference to a well-defined set of
code points; the proposed replacement text is, quite literally, nonsense.

> 
> Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 10 07:20:58 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF8F28C1A8 for ; Thu, 10 Sep 2009 07:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level: 
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaOXDRlUM75S for ; Thu, 10 Sep 2009 07:20:57 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71D6328C1A0 for ; Thu, 10 Sep 2009 07:20:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlkRE-000AbE-OH for radiusext-data0@psg.com; Thu, 10 Sep 2009 14:15:52 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MlkR4-000AaA-MD for radiusext@ops.ietf.org; Thu, 10 Sep 2009 14:15:50 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id AA37512345DC; Thu, 10 Sep 2009 16:15:38 +0200 (CEST)
Message-ID: <4AA90A0A.7020404@deployingradius.com>
Date: Thu, 10 Sep 2009 16:15:38 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Jari Arkko 
CC: Alper Yegin ,  "'Romascanu, Dan \(Dan\)'" , bernarda@microsoft.com, mbeadles@endforce.com, pasi.eronen@nokia.com,  rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
References: <200909081535.n88FZL4e026640@boreas.isi.edu>  <001501ca3130$371b7ce0$a55276a0$@net> <4AA77B10.9030209@freeradius.org> <4AA782F2.3000908@ericsson.com> <4AA79A9B.4000104@freeradius.org> <4AA79E3A.9010401@ericsson.com> <004701ca314d$8a927fa0$9fb77ee0$@net> <4AA7ACD4.8010204@piuha.net> <006601ca3154$b2cd66e0$186834a0$@net> <005a01ca3156$12d7c700$38875500$@yegin@yegin.org> <4AA7BA69.7070701@freeradius.org> <4AA7DF81.2010609@piuha.net>
In-Reply-To: <4AA7DF81.2010609@piuha.net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Jari Arkko wrote:
> Section 1.2 boilerplate is not according to RFC 2119.

  Fixed.

> grammer => grammar

  Fixed.

>> o Section 2.1 did not contain ABNF for the UTF-8 form of the  
>>             realm. This makes it impossible to create an
>> inter-operable               internationalized version of the realm
> 
> But the realm was not specified to carry UTF-8. As the RFC said later:
...
> I realize that there may be other reasons -- such as compatibility with
> EAP RFCs that demands plain UTF-8 should be used. However, the argument
> above does not seem correct.

  The later text discusses this, and could be merged:

o The requirement in Section 2.1 that realms are ASCII conflicts
  with the Extensible Authentication Protocol (EAP) and RADIUS, which
  are both 8-bit clean, and which both recommend the use of UTF-8 for
  identities.

>> o Section 2.5 required mappings that are language-specific,  
>>             and which are nearly impossible to perform correctly
>> without               information about that language.
> 
> I guess this means Section 2.4 of RFC 4282, right?

  Yes.

> Also, the mappings required in that section are to be done by the end
> systems where the user types in the strings. Such end systems can be
> aware of what character set and language the user employs. I agree that
> none of the intermediate systems could have any idea about that, but
> AFAICT that was not required by the RFC.

  The suggestion was for proxies to perform normalized comparisons,
which requires the mappings.

  The update suggests (essentially) using "strcmp" for comparisons.

  That could say instead:

o Section 2.4 required mappings that are language-specific,
  and which are nearly impossible for intermediate nodes to perform
  correctly without information about that language.

>>  normalization form NFC for NAIs is REQUIRED.
> Expand NFC

  Done.

>> The grammar for       the username is based on [RFC0821], and the
>> grammar for the realm is        the user and realm portion is based on
>> a combination of the "nai"       an updated version of
>> [RFC1035].        defined in [RFC4282] Section 2.1, and the
>> "utf8-addr-spec" defined in               [RFC5335] Section 4.4.
> I was confused by this statement. Do you mean that you normatively refer
> 4282 for these definitions or that this is how you arrived at the ABNF?

  It means how I arrived at the ABNF.

> I think you should just say "this is the ABNF" and if there's any
> rationale that needs to be said, add it to Section 1.4.

  Ok.  It looked awkward to add it to 1.4, so I added it to the appendix.

>> .fi
> 
> Nroff problem...

  Fixed.

>> in question. Therefore, the username portion SHOULD be treated as
> 
> Since you changed the ABNF names, this probably should now be
> utf8-username to be exact what you mean by the username portion.

  Fixed.

>> In order to ensure a canonical representation
> 
> I would like to understand this better. 4282 provided canonicalization
> in order to make sure that when you look up a username db lookups and
> routing table comparisons work. Does the bis have the same property, and
> how so?

  We can say:

The form suggested in [RFC4282] depended on
intermediate nodes performing canonicalizations based on insufficient
information, which meant that the form was not canonical.  This
document instead suggests (Section 2.10) that the realm owner provide
a canonical form of the realm, and that all intermediate nodes use
that form without modification.

  This means that there is only one canonical form: that supplied by the
realm owner.

>>    In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
>>    systems to perform NAI comparisons, matching, and AAA routing based
>>    on the NAI as it is received.  This requirement provides a canonical
>>    representation, ensures that intermediate systems such as AAA proxies
>>    do not need to perform translations, and can be expected to work
>>    through systems that are unaware of international character sets.
> 
> I though that this was the case already with RFC 4282, but maybe I'm
> missing something.

  See the above comment.  The *intent* in 4282 was to provide a
canonical representation.  Unfortunately, it cannot be used to provide that.

>> For example, much of the common realm routing can be done on the  
>>             "utf8-realm" portion of NAI, through simple checks for
>> equality.
> 
> I thought that suffix match was also a possibility in some systems.

  A *partial* suffix match?  (e.g. foo.example.com matches example.com)

  That's possible, but fairly rare.

>> There are, however, a number of problems with this approach. A AAA  
>>             proxy may not have sufficient information in order to
>> perform the               ToAscii conversion properly. ...

> And here's the tradeoff for using UTF-8 as opposed to IDN unaware name
> slots. I was trying to think about situations where the DNS lookups are
> needed and whether they'd form a problem. Can you name a few of the
> situations where DNS name lookups from NAIs are actually used today?

  Diameter.  RadSec (RADIUS over SSL over TCP), which is being
standardized right now.

  It's pretty rare, which means we should get it right before we have
wide-spread deployments.

  I'm not aware of any scenario where AAA servers would use arbitrary
strings supplied by the user to do DNS lookups, or why anyone would
think that this is a good idea.

  It would be MUCH better to have a AAA routing protocol, where "home"
servers could propagate realm / punycode data to proxies.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 12 12:57:14 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA203A6999 for ; Sat, 12 Sep 2009 12:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.417
X-Spam-Level: *
X-Spam-Status: No, score=1.417 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzlJhgHQ982m for ; Sat, 12 Sep 2009 12:57:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4ED13A6825 for ; Sat, 12 Sep 2009 12:57:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmYfg-000H62-3V for radiusext-data0@psg.com; Sat, 12 Sep 2009 19:54:08 +0000
Received: from [65.55.116.34] (helo=blu0-omc1-s23.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmYfU-000H4h-Ec for radiusext@ops.ietf.org; Sat, 12 Sep 2009 19:54:06 +0000
Received: from BLU137-W36 ([65.55.116.8]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Sep 2009 12:53:56 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_eef42904-7302-4c5b-9a39-40ee19fd8f02_"
X-Originating-IP: [97.120.172.189]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG Virtual Interim Meeting October 13, 2009
Date: Sat, 12 Sep 2009 12:53:55 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Sep 2009 19:53:56.0315 (UTC) FILETIME=[C325F2B0:01CA33E2]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_eef42904-7302-4c5b-9a39-40ee19fd8f02_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADEXT WG will be having a Virtual Interim Meeting on Tuesday=2C Octobe=
r 13=2C 2009 from 8:00 AM - 10:00 AM PDT. =20

Details on the agenda and conference calling parameters for the meeting wil=
l be available here:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt





--_eef42904-7302-4c5b-9a39-40ee19fd8f02_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






The RADEXT WG will be having a Virtual Interim Meeting on Tuesday=2C Octobe=
r 13=2C 2009 from 8:00 AM - 10:00 AM PDT. =3B 

Details on the ag=
enda and conference calling parameters for the meeting will be available he=
re:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt

=




=

--_eef42904-7302-4c5b-9a39-40ee19fd8f02_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 12 13:16:19 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20193A69A5 for ; Sat, 12 Sep 2009 13:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.426
X-Spam-Level: *
X-Spam-Status: No, score=1.426 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT4Ry8DkUzD4 for ; Sat, 12 Sep 2009 13:16:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4C663A69B2 for ; Sat, 12 Sep 2009 13:16:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmYyt-000JpR-SV for radiusext-data0@psg.com; Sat, 12 Sep 2009 20:13:59 +0000
Received: from [65.55.116.14] (helo=blu0-omc1-s3.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmYyj-000Joq-1I for radiusext@ops.ietf.org; Sat, 12 Sep 2009 20:13:57 +0000
Received: from BLU137-W16 ([65.55.116.7]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Sep 2009 13:13:48 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_eec3214d-b35d-4623-92f3-b729d44cd4f1_"
X-Originating-IP: [97.120.172.189]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT Virtual Interim Agenda - Take One
Date: Sat, 12 Sep 2009 13:13:48 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Sep 2009 20:13:48.0118 (UTC) FILETIME=[8984A760:01CA33E5]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_eec3214d-b35d-4623-92f3-b729d44cd4f1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba 
David Nelson 

Tuesday=2C October 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)


8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Document Status=20

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls




--_eec3214d-b35d-4623-92f3-b729d44cd4f1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba <=3Bbe=
rnard_aboba@hotmail.com>=3B
David Nelson <=3Bd.b.nelson@comcast.net&=
gt=3B

Tuesday=2C October 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:=
00 EDT)


8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
=
   Document Status 

Documents completing IETF Last Call (20 minutes)=


8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  min=
utes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documen=
ts Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C =
Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-=
radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 mi=
nutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server
9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
h=
ttp://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work It=
ems (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefa=
n Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynam=
ic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 mi=
nutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls


=

<=
span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=
=2C 85)=3B text-decoration: underline=3B">

=

--_eec3214d-b35d-4623-92f3-b729d44cd4f1_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 13 11:27:57 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609E13A690F for ; Sun, 13 Sep 2009 11:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.182
X-Spam-Level: 
X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7sh5bhAqcjC for ; Sun, 13 Sep 2009 11:27:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5466A3A6843 for ; Sun, 13 Sep 2009 11:27:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmtkM-000KCK-Cf for radiusext-data0@psg.com; Sun, 13 Sep 2009 18:24:22 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MmtkA-000K9k-IP for radiusext@ops.ietf.org; Sun, 13 Sep 2009 18:24:19 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id BCB9C1234282; Sun, 13 Sep 2009 20:24:08 +0200 (CEST)
Message-ID: <4AAD38C8.9030408@deployingradius.com>
Date: Sun, 13 Sep 2009 20:24:08 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: RADEXT Virtual Interim Agenda - Take One
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> RADEXT WG Virtual Interim Agenda

  On a related note, how many people plan on being at the next IETF?

  I'm not sure yet if I will be able to make it.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 05:17:42 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CFA3A69EE for ; Wed, 16 Sep 2009 05:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.736
X-Spam-Level: 
X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJm3fsVhxrSw for ; Wed, 16 Sep 2009 05:17:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95E3E3A696B for ; Wed, 16 Sep 2009 05:17:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MntOf-000AME-Nw for radiusext-data0@psg.com; Wed, 16 Sep 2009 12:14:05 +0000
Received: from [76.96.27.227] (helo=QMTA12.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MntOV-000AKZ-IJ for radiusext@ops.ietf.org; Wed, 16 Sep 2009 12:14:04 +0000
Received: from OMTA22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id hQDV1c0041vN32cACQDvKL; Wed, 16 Sep 2009 12:13:55 +0000
Received: from NEWTON603 ([71.232.143.198]) by OMTA22.emeryville.ca.mail.comcast.net with comcast id hQKA1c00A4H2mdz8iQKBNg; Wed, 16 Sep 2009 12:19:12 +0000
From: "Dave Nelson" 
To: 
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2> <4AA6BA94.9020209@deployingradius.com> 
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 08:13:54 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcowxFRURay+VInzS6yC3o/iOHxDAAGAliYg
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard wrote...

> > If the RADIUS server has to parse it, then complex attributes are
> > allowed for authentication and security...
>
> I think the question is why the exemption should be so broad.=A0 The
> security and authentication attributes described in Appendix B =
required
> computation.=A0 That is the RADIUS server had to add code in order to
> compare the authentication result presented by the RADIUS client with =
the
> result it calculated based on its own data.=20
>
> However, if the RADIUS server doesn't have to do any computation (e.g.
> if it is just sending security or authentication-related data to the
> RADIUS client), then there is no intrinsic reason why RADIUS server
> code needs to change.=A0 In that case, why should the exemption apply?

I don't think I ever saw an answer to this on the list.  Could we close =
out
this discussion, and perhaps craft some revised text, before the next =
draft
version is submitted?


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 05:31:08 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F4D3A688D for ; Wed, 16 Sep 2009 05:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.883
X-Spam-Level: 
X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjB3rmv-GNLU for ; Wed, 16 Sep 2009 05:31:07 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC7313A6848 for ; Wed, 16 Sep 2009 05:31:06 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mntd6-000CXj-To for radiusext-data0@psg.com; Wed, 16 Sep 2009 12:29:00 +0000
Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mntcv-000CVm-S4 for radiusext@ops.ietf.org; Wed, 16 Sep 2009 12:28:58 +0000
Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id hQ0b1c00A0lTkoCA4QUq99; Wed, 16 Sep 2009 12:28:50 +0000
Received: from NEWTON603 ([71.232.143.198]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id hQUo1c00D4H2mdz8QQUpUD; Wed, 16 Sep 2009 12:28:50 +0000
From: "Dave Nelson" 
To: 
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2> <4AA6BA94.9020209@deployingradius.com>
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 08:28:50 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4AA6BA94.9020209@deployingradius.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcowwS1Ia7t2arAPQAGrcQPLaTDGnAGBf/Ag
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok wrote...
> 
>   ?
> 
>    Does the attribute:
> 
>     * define a complex data type
>     * that the RADIUS server and/or client will not treat as opaque data
>       (see Section A.1.3)

Uh, there is no Appendix A.1.3 in the -08 version.  Is that now A.1.2?

A.1.2. Opaque data types

   Does the attribute encapsulate an existing data structure defined
   outside of the RADIUS specifications?  Can the attribute be treated
   as opaque data by RADIUS servers (including proxies?)  If both
   questions can be answered affirmatively, a complex structure MAY be
   used in a RADIUS specification.

   The specification of the attribute SHOULD define the encapsulating
   attribute to be of type String.  The specification SHOULD refer to an
   external document defining the structure.  The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

What's the status of an attribute if the author claims that it can be opaque
to a RADIUS server implementation, but the format of the data payload
contained in the attribute is not defined in any other document, but rather
defined, in standard RADIUS attribute fashion, within the RADIUS extension
document itself?  Does that qualify for meeting the opaqueness test of
A.1.2?
 
>   If the RADIUS server can treat it as opaque data, then it falls under
> the purview of A.1.3.  It is permitted, independent of it being used for
> authentication, security, or anything else.
> 
>   If the RADIUS server has to parse it, then complex attributes are
> allowed for authentication and security...

I want to further nail down these two words: authentication, security.

Does authentication mean that the attribute is used to implement a RADIUS
Authentication Method?

Does security means that the attribute is used to provide message integrity
or message confidentiality for the RADIUS datagram itself?

Those extended definitions match what I think is the intent.

On the other hand, security could mean all sorts of things.  It could be a
key-wrap attribute for a key to be used in the NAS or the attached
end-point.  It could be a security policy such as access control information
or a mandatory cipher-suite.  I could go on.  Lots and lots of things fall
under the moniker of security.

I'd really like to see this definitional issue tightened up before the next
draft version is issued.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 06:29:01 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8385D3A69C0 for ; Wed, 16 Sep 2009 06:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.958
X-Spam-Level: 
X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sob-FhlNkQz8 for ; Wed, 16 Sep 2009 06:29:00 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E94A33A69F8 for ; Wed, 16 Sep 2009 06:28:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnuX6-000K6O-RD for radiusext-data0@psg.com; Wed, 16 Sep 2009 13:26:52 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnuWv-000K2b-2I for radiusext@ops.ietf.org; Wed, 16 Sep 2009 13:26:49 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 54FB41234282; Wed, 16 Sep 2009 15:19:43 +0200 (CEST)
Message-ID: <4AB0E78F.60107@deployingradius.com>
Date: Wed, 16 Sep 2009 15:26:39 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Dave Nelson 
CC: radiusext@ops.ietf.org
Subject: Re: Issue 313:  Security Exemption
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2> <4AA6BA94.9020209@deployingradius.com> 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Dave Nelson wrote:
>>     * define a complex data type
>>     * that the RADIUS server and/or client will not treat as opaque data
>>       (see Section A.1.3)
> 
> Uh, there is no Appendix A.1.3 in the -08 version.  Is that now A.1.2?

  Yes.

> What's the status of an attribute if the author claims that it can be opaque
> to a RADIUS server implementation, but the format of the data payload
> contained in the attribute is not defined in any other document, but rather
> defined, in standard RADIUS attribute fashion, within the RADIUS extension
> document itself?  Does that qualify for meeting the opaqueness test of
> A.1.2?

  See the last sentence you quoted:

   The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

  If it's an opaque type, then the format shouldn't be described in a
RADIUS document.

>>   If the RADIUS server has to parse it, then complex attributes are
>> allowed for authentication and security...
> 
> I want to further nail down these two words: authentication, security.
> 
> Does authentication mean that the attribute is used to implement a RADIUS
> Authentication Method?
> 
> Does security means that the attribute is used to provide message integrity
> or message confidentiality for the RADIUS datagram itself?
> 
> Those extended definitions match what I think is the intent.

  I believe so.  How about breaking those definitions out into a new
section:

A.1.2. Transport of Authentication and Security Data

   Does the data provide authentication and/or security capabilities, as
   outlined below?  If so, it SHOULD be encapsulated in a [RFC2865]
   format RADIUS attribute.  It SHOULD NOT be encapsulated in a
   [RFC2865] format RADIUS VSA.

      * Complex data types that carry authentication methods which
        RADIUS servers are expected to parse and verify as part of
        an authentication process.

      * Complex data types that carry security information intended
        to increase the security of the RADIUS protocol itself.

   Any data type carrying authentication and/or security data that is
   not meant to be parsed by a RADIUS server is an "opaque data type",
   as defined below.

> On the other hand, security could mean all sorts of things.  It could be a
> key-wrap attribute for a key to be used in the NAS or the attached
> end-point.

  e.g. the MS-MPPE-keys... but those could fit into the standard RADIUS
data model with a bit of tweaking.

> I'd really like to see this definitional issue tightened up before the next
> draft version is issued.

  Suggested text is above.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 08:20:46 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4065C3A6899 for ; Wed, 16 Sep 2009 08:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.843
X-Spam-Level: 
X-Spam-Status: No, score=0.843 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl+grAuCHRog for ; Wed, 16 Sep 2009 08:20:45 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CADE3A686B for ; Wed, 16 Sep 2009 08:20:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnwH6-00088G-Bl for radiusext-data0@psg.com; Wed, 16 Sep 2009 15:18:28 +0000
Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnwGw-00087V-DL for radiusext@ops.ietf.org; Wed, 16 Sep 2009 15:18:25 +0000
Received: from OMTA18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id hQaW1c0011bwxycA1THn3z; Wed, 16 Sep 2009 15:17:47 +0000
Received: from NEWTON603 ([71.232.143.198]) by OMTA18.emeryville.ca.mail.comcast.net with comcast id hTPB1c00D4H2mdz8eTPCDi; Wed, 16 Sep 2009 15:23:12 +0000
From: "Dave Nelson" 
To: 
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2> <4AA6BA94.9020209@deployingradius.com>  <4AB0E78F.60107@deployingradius.com>
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 11:18:19 -0400
Message-ID: <53C1B452056244809265A07DC6AF80F8@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4AB0E78F.60107@deployingradius.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: Aco20VSq07zOc9Z7TwSaaP/ze6X38wAD1Yfg
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok writes...

>   See the last sentence you quoted:
> 
>    The specification SHOULD
>    NOT define or describe the structure, as discussed above in Section
>    2.1.3.
> 
>   If it's an opaque type, then the format shouldn't be described in a
> RADIUS document.

Right.  Hopefully future authors will take that to heart.  :-)

>   I believe so.  How about breaking those definitions out into a new
> section:
> 
> A.1.2. Transport of Authentication and Security Data
> 
>    Does the data provide authentication and/or security capabilities, as
>    outlined below?  If so, it SHOULD be encapsulated in a [RFC2865]
>    format RADIUS attribute.  It SHOULD NOT be encapsulated in a
>    [RFC2865] format RADIUS VSA.
> 
>       * Complex data types that carry authentication methods which
>         RADIUS servers are expected to parse and verify as part of
>         an authentication process.
> 
>       * Complex data types that carry security information intended
>         to increase the security of the RADIUS protocol itself.
> 
>    Any data type carrying authentication and/or security data that is
>    not meant to be parsed by a RADIUS server is an "opaque data type",
>    as defined below.

That text looks good to me.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 09:30:23 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DB33A692A for ; Wed, 16 Sep 2009 09:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.389
X-Spam-Level: *
X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrFfCrjESmPI for ; Wed, 16 Sep 2009 09:30:22 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 516F43A6895 for ; Wed, 16 Sep 2009 09:30:22 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnxJi-000Hz4-Cu for radiusext-data0@psg.com; Wed, 16 Sep 2009 16:25:14 +0000
Received: from [65.55.111.150] (helo=blu0-omc4-s11.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnxJP-000Hwt-CI for radiusext@ops.ietf.org; Wed, 16 Sep 2009 16:25:12 +0000
Received: from BLU137-W32 ([65.55.111.137]) by blu0-omc4-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 09:24:55 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_46b58ef5-5872-4128-808f-149a7751ec96_"
X-Originating-IP: [131.107.0.106]
From: Bernard Aboba 
To: "David B. Nelson" , "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 09:24:54 -0700
Importance: Normal
In-Reply-To: <53C1B452056244809265A07DC6AF80F8@NEWTON603>
References:  <4A9FC353.3050104@deployingradius.com> <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2> <4AA6BA94.9020209@deployingradius.com>  <4AB0E78F.60107@deployingradius.com> <53C1B452056244809265A07DC6AF80F8@NEWTON603>
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Sep 2009 16:24:55.0440 (UTC) FILETIME=[39DB4900:01CA36EA]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_46b58ef5-5872-4128-808f-149a7751ec96_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


+1

> That text looks good to me.



--_46b58ef5-5872-4128-808f-149a7751ec96_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






+1

>=3B That text looks good to me.



=

--_46b58ef5-5872-4128-808f-149a7751ec96_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 10:53:21 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758C13A6B9B for ; Wed, 16 Sep 2009 10:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.398
X-Spam-Level: *
X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fox97sdtC5UU for ; Wed, 16 Sep 2009 10:53:20 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76DA43A6B9A for ; Wed, 16 Sep 2009 10:53:20 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnyfW-00011O-PF for radiusext-data0@psg.com; Wed, 16 Sep 2009 17:51:50 +0000
Received: from [65.55.116.16] (helo=blu0-omc1-s5.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnyfM-0000za-BY for radiusext@ops.ietf.org; Wed, 16 Sep 2009 17:51:48 +0000
Received: from BLU137-W26 ([65.55.116.7]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 10:51:39 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_fd1f39e7-4177-487b-9354-1fa6eb06b008_"
X-Originating-IP: [131.107.0.77]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT Virtual Interim Agenda - Take One
Date: Wed, 16 Sep 2009 10:51:39 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Sep 2009 17:51:39.0795 (UTC) FILETIME=[57E4D630:01CA36F6]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_fd1f39e7-4177-487b-9354-1fa6eb06b008_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba 
David Nelson 

Tuesday=2C October 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)


8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Document Status=20

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls




--_fd1f39e7-4177-487b-9354-1fa6eb06b008_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












RADEXT WG Virtual Interim Agen=
da

Chairs: Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B<=
br>David Nelson <=3Bd.b.nelson@comcast.net>=3B

Tuesday=2C Octobe=
r 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)


8:00 AM - 8=
:20 AM  Preliminaries
   Jabber scribe
   Document Status 

Doc=
uments completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Desi=
gn Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org=
/html/draft-ietf-radext-design

Documents Completing WG Last Call (20=
 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
=
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 A=
M Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.or=
g/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over=
 TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draf=
t-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 A=
M - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http:=
//tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - =
9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.or=
g/html/draft-dekok-radext-dtls




=

--_fd1f39e7-4177-487b-9354-1fa6eb06b008_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 10:53:45 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15563A6B9A for ; Wed, 16 Sep 2009 10:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.406
X-Spam-Level: *
X-Spam-Status: No, score=1.406 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3F8Q49aFhpb for ; Wed, 16 Sep 2009 10:53:45 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B52403A6A7B for ; Wed, 16 Sep 2009 10:53:44 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnygH-00015i-7U for radiusext-data0@psg.com; Wed, 16 Sep 2009 17:52:37 +0000
Received: from [65.55.116.28] (helo=blu0-omc1-s17.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mnyg1-00013r-Hk for radiusext@ops.ietf.org; Wed, 16 Sep 2009 17:52:33 +0000
Received: from BLU137-W19 ([65.55.116.8]) by blu0-omc1-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 10:52:21 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_"
X-Originating-IP: [131.107.0.77]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG Virtual Interim Meeting October 13, 2009
Date: Wed, 16 Sep 2009 10:52:21 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Sep 2009 17:52:21.0360 (UTC) FILETIME=[70AB2700:01CA36F6]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








The RADEXT WG will be having a Virtual Interim Meeting on Tuesday=2C Octobe=
r 13=2C 2009 from 8:00 AM - 10:00 AM PDT. =20

Details on the agenda and conference calling parameters for the meeting wil=
l be available here:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt





--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












The RADEXT WG will be havi=
ng a Virtual Interim Meeting on Tuesday=2C October 13=2C 2009 from 8:00 AM =
- 10:00 AM PDT. =3B 

Details on the agenda and conference callin=
g parameters for the meeting will be available here:
http://www.drizzle.=
com/~aboba/RADEXT/oct-virtual-interim.txt





=

--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 16 10:54:54 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB2D28C0DE for ; Wed, 16 Sep 2009 10:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.115
X-Spam-Level: 
X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uizRJI--2Rn4 for ; Wed, 16 Sep 2009 10:54:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A52F3A692E for ; Wed, 16 Sep 2009 10:54:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnyhS-0001GY-9X for radiusext-data0@psg.com; Wed, 16 Sep 2009 17:53:50 +0000
Received: from [65.55.116.25] (helo=blu0-omc1-s14.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MnyhI-0001EW-0Y for radiusext@ops.ietf.org; Wed, 16 Sep 2009 17:53:47 +0000
Received: from BLU137-W12 ([65.55.116.7]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 10:53:39 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_"
X-Originating-IP: [131.107.0.77]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
Date: Wed, 16 Sep 2009 10:53:40 -0700
Importance: Normal
In-Reply-To: <4AA6C0B2.8040404@venaas.com>
References:  <4AA6C0B2.8040404@venaas.com> 
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Sep 2009 17:53:39.0581 (UTC) FILETIME=[9F4ABAD0:01CA36F6]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Here are my comments:

=20

Category: Proposed Standards

=20

[BA] My impression was that this document (like RADIUS over TLS and RADIUS =
over DTLS) was targeted for Experimental status.=20

=20

Abstract

   The Remote Authentication Dial In User Server (RADIUS) Protocol has
   traditionally used the User Datagram Protocol (UDP) as it's
   underlying transport layer.  This document defines RADIUS over the
   Transmission Control Protocol (TCP).


[BA] It might be worth stating that this specification was developed primar=
ily for addressing the transport issues inherent in RADIUS over TLS=2C and =
that it is not intended for use by itself.   =20

=20

Section 1

=20

      * Connectionless transport.  Neither clients nor servers can
      reliably detect when the other is down.  This information has to
      be deduced instead from the absence of a reply to a request.


[BA] Determining when a client or server is down is not automatically solve=
d by choice of a reliable transport.

For example=2C without an application layer watchdog=2C an application rely=
ing on TCP would typically need to wait

until the connection timed out before trying another server.  This is the p=
roblem identified by RFC 2865=2C which talks about UDP be used for faster f=
ailover than would be permitted by TCP without a watchdog.  However=2C fail=
over as envisaged by RFC 2865 does not require deducing that a server is "d=
own" based on lack of a reply=3B  doing so would require a much longer wait=
ing interval than implementations typically provide.  RADIUS over UDP imple=
mentations typically don't care whether the server is "down" or not=3B they=
 only care that it hasn't responded after set time interval or number of re=
tries.  However=2C none of this is specified in RFC 2865 (or RFC 5080)=2C s=
o the quality of the failover algorithm will vary between implementations. =
 This I think is the

more relevant point -- lack of a standardized failover algorithm.  Presumab=
ly=2C this document can address that problem.=20

=20

   As RADIUS is widely deployed=2C and has been widely deployed for well
   over a decade=2C these issues are relatively minor.  However=2C new
   systems may be interested in choosing a different set of trade-offs
   than those outlined in [RFC2865] Section 2.4.  For those systems=2C we
   define RADIUS over TCP.


[BA] I would disagree that the failover problem is necessarily minor=3B  in=
 implementations I'm familiar with=2C developing a stable and reliable fail=
over algorithm was a major pain.  With respect to the reasoning behind the =
development of RADIUS over TCP=2C is the issue really the need for a "diffe=
rent set of tradeoffs"=2C or is the issue the different set of needs that m=
anifest themselves in proxy-proxy transport situations?  As described in RF=
C 3539=2C NAS-proxy scenarios do not really benefit from reliable transport=
 because the connection would be likely to run with the minimum congestion =
window most of the time.  As a result=2C using reliable transport just gene=
rates a lot of ACK traffic without making use of the congestion control/win=
dow management benefits of TCP. This is not necessarily the case for proxy-=
proxy transport where the volume may be quite a bit higher. =20

=20

Section 1.1

=20

   The intent of this document is to address transport issues related to
   RadSec [RADSEC].  The use of "bare" TCP transport is NOT RECOMMENDED=2C
   as there has been little implementational or operational experience
   with it.  Additionally=2C [RFC2865] Section 2.4 contains a list of
   reasons why UDP was originally chosen as the transport protocol for
   RADIUS.  UDP SHOULD be used as transport protocol in all cases where
   the rationale given in [RFC2865] Section 2.4 applies.


[BA] I think you might say a bit more about the applicability of RADIUS ove=
r "bare" TCP.  For example=2C that

it is only useful in proxy-proxy scenarios where the traffic is protected b=
y TLS.  The reasons given might include both transport as well as security =
and interoperability concerns.   For example=2C we have seen interoperabili=
ty problems result in situations where application layer protocols can be t=
ransported in multiple ways (e.g. SIP)=2C and proxy-proxy scenarios can ben=
efit from stronger/more flexible security=2C as envisaged in RADIUS over TL=
S. =20

=20

=20

=20

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














Here are my comments:

 =3B

Category: Proposed Standards

 =3B

[BA] My impression was that this =3Bdocument (like RADIUS over TLS and =
RADIUS over DTLS) was targeted for Experimental status. 

 =3B

Abstract

 =3B =3B The Remote Authentication Dial In User Ser=
ver (RADIUS) Protocol has
 =3B =3B traditionally used the User D=
atagram Protocol (UDP) as it's
 =3B =3B underlying transport lay=
er. =3B This document defines RADIUS over the
 =3B =3B Trans=
mission Control Protocol (TCP).


[BA] It might be worth stating that this specification was developed primar=
ily for addressing the transport issues inherent in RADIUS over TLS=2C and =
that it is not intended for use by itself. =3B =3B =3B 

 =3B

Section 1

 =3B

 =3B =3B =3B =3B =3B * Connectionless transport. =
=3B Neither clients nor servers can
 =3B =3B =3B =3B&nbs=
p=3B reliably detect when the other is down. =3B This information has t=
o
 =3B =3B =3B =3B =3B be deduced instead from the a=
bsence of a reply to a request.


[BA] Determining when a client or server is down is not automatically solve=
d by choice of a reliable transport.

For example=2C without an application layer watchdog=2C an application rely=
ing on TCP would typically need to wait

until the connection timed out before trying another server. =3B This i=
s the problem identified by RFC 2865=2C which =3Btalks about UDP be use=
d =3Bfor faster =3Bfailover than would be permitted by =3BTCP w=
ithout a watchdog. =3B However=2C =3Bfailover as envisaged by RFC 2=
865 does not require deducing that a =3Bserver is "down" based on lack =
of a reply=3B =3B =3Bdoing so would require a much longer waiting i=
nterval than implementations typically provide. =3B RADIUS over UDP imp=
lementations typically don't care whether the server is "down" or not=3B th=
ey only care that it hasn't responded after set time interval or number of =
retries. =3B =3BHowever=2C none of this is specified in RFC 2865 (o=
r RFC 5080)=2C so =3Bthe quality of the failover algorithm will vary be=
tween implementations. =3B This I think is the

more relevant point -- lack of a standardized failover algorithm. =3B P=
resumably=2C this document can address that problem. 

 =3B

 =3B =3B As RADIUS is widely deployed=2C and has been widely deploy=
ed for well
 =3B =3B over a decade=2C these issues are relativel=
y minor. =3B However=2C new
 =3B =3B systems may be interest=
ed in choosing a different set of trade-offs
 =3B =3B than those=
 outlined in [RFC2865] Section =3B2.4. =3B For t=
hose systems=2C we
 =3B =3B define RADIUS over TCP.


[BA] I would disagree that the failover problem is necessarily minor=3B&nbs=
p=3B in implementations I'm familiar with=2C developing a stable and reliab=
le failover algorithm was a major pain. =3B With respect to the reasoni=
ng behind the development of RADIUS over TCP=2C is the issue really the nee=
d for a "different set of tradeoffs"=2C or is the issue the =3Bdifferen=
t set of needs that =3Bmanifest themselves in proxy-proxy transport sit=
uations? =3B =3BAs described in RFC 3539=2C NAS-proxy =3Bscenar=
ios do not really benefit from reliable transport because the connection&nb=
sp=3Bwould be likely to =3Brun with =3Bthe minimum congestion windo=
w most of the time. =3B As a result=2C using reliable transport just ge=
nerates a lot of ACK traffic without making use of the congestion control/w=
indow management benefits of TCP. This is not necessarily the case for prox=
y-proxy transport where the volume may be quite a bit higher. =3B 

 =3B

Section 1.1

 =3B

 =3B =3B The intent of this document is to address transport issues=
 related to
 =3B =3B RadSec [RADSEC=
]. =3B The use of "bare" TCP transport is NOT RECOMMENDED=2C=

 =3B =3B as there has been little implementational or operation=
al experience
 =3B =3B with it. =3B Additionally=2C [RFC2865] Section =3B2.4 contains a list of
 =3B&nbs=
p=3B reasons why UDP was originally chosen as the transport protocol for =3B =3B RADIUS. =3B UDP SHOULD be used as transport protocol =
in all cases where
 =3B =3B the rationale given in [RFC2=
865] Section =3B2.4 applies.


[BA] I think you might say a bit more about the =3Bapplicability of&nbs=
p=3BRADIUS over "bare" TCP. =3B For example=2C that

it is only useful in proxy-proxy scenarios where the traffic is protected b=
y TLS. =3B The reasons given might include both transport as well as se=
curity and interoperability concerns. =3B =3B =3BFor example=2C=
 we have seen interoperability problems result in situations where applicat=
ion layer protocols can be transported in multiple ways (e.g. SIP)=2C and p=
roxy-proxy scenarios can benefit from stronger/more flexible security=2C as=
 envisaged in RADIUS over TLS. =3B 

 =3B

 =3B

 =3B

=

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 02:45:54 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0585B3A67DF for ; Thu, 17 Sep 2009 02:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.94
X-Spam-Level: 
X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoS1VVm-IR23 for ; Thu, 17 Sep 2009 02:45:52 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8626A3A6946 for ; Thu, 17 Sep 2009 02:45:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoDWd-000O5v-Ns for radiusext-data0@psg.com; Thu, 17 Sep 2009 09:43:39 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoDWU-000O5D-3i for radiusext@ops.ietf.org; Thu, 17 Sep 2009 09:43:37 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 7422A1234282; Thu, 17 Sep 2009 11:37:02 +0200 (CEST)
Message-ID: <4AB204BE.3090305@deployingradius.com>
Date: Thu, 17 Sep 2009 11:43:26 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item
References:  <4AA6C0B2.8040404@venaas.com> 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> [BA] My impression was that this document (like RADIUS over TLS and
> RADIUS over DTLS) was targeted for Experimental status.

  Fixed.

> Abstract
...
> [BA] It might be worth stating that this specification was developed
> primarily for addressing the transport issues inherent in RADIUS over
> TLS, and that it is not intended for use by itself.   

  That text is also in Section 1.1, but it doesn't hurt to emphasize it
here.

> [BA] Determining when a client or server is down is not automatically
> solved by choice of a reliable transport.

  TCP can provide a positive statement when a connection is down.

> For example, without an application layer watchdog, an application
> relying on TCP would typically need to wait
> until the connection timed out before trying another server.

  Yes.  Or, receiving a FIN when a connection is closed.

>  This is
> the problem identified by RFC 2865, which talks about UDP be used for
> faster failover than would be permitted by TCP without a watchdog. 
> However, failover as envisaged by RFC 2865 does not require deducing
> that a server is "down" based on lack of a reply;  doing so would
> require a much longer waiting interval than implementations typically
> provide.  RADIUS over UDP implementations typically don't care whether
> the server is "down" or not; they only care that it hasn't responded
> after set time interval or number of retries.

  For robust proxying, a number of implementations track server state.
They can implement simple checks such as "no response to any packet in
the last 60 seconds".  They can then mark a server as "down", remove it
from any pool of active servers, and refuse to forward *new* packets to it.

>  However, none of this is
> specified in RFC 2865 (or RFC 5080), so the quality of the failover
> algorithm will vary between implementations.  This I think is the
> more relevant point -- lack of a standardized failover algorithm. 
> Presumably, this document can address that problem.

 Hmm... I'm not so sure.  Failover algorithms are hard to get right.
And I don't think that the TCP document is the best place to discuss
general RADIUS failover.

  Defining a TCP watchdog is OK, but that's just referencing RFC 3539.

  Maybe the text should say instead:

* Connectionless transport.  Neither clients nor servers receive
positive statements that a "connection" is down.  This information has
to be deduced instead from the absence of a reply to a request.

> [BA] I would disagree that the failover problem is necessarily minor; 
> in implementations I'm familiar with, developing a stable and reliable
> failover algorithm was a major pain.

  Agreed.

>  With respect to the reasoning
> behind the development of RADIUS over TCP, is the issue really the need
> for a "different set of tradeoffs", or is the issue the different set of
> needs that manifest themselves in proxy-proxy transport situations?

  Both, I think.  Suggested rewording:

As RADIUS is widely deployed, and has been widely deployed for well
over a decade, these issues have been minor in some use-cases, and
problematic in others.  New systems may be interested in choosing a
different set of trade-offs than those outlined in [RFC2865] Section
2.4.  New systems may also be interested in choosing a more reliable
transport for use-cases such as inter-server proxying.  For those
systems, we define RADIUS over TCP.

> [BA] I think you might say a bit more about the applicability of RADIUS
> over "bare" TCP.  For example, that
> it is only useful in proxy-proxy scenarios where the traffic is
> protected by TLS.  The reasons given might include both transport as
> well as security and interoperability concerns.   For example, we have
> seen interoperability problems result in situations where application
> layer protocols can be transported in multiple ways (e.g. SIP), and
> proxy-proxy scenarios can benefit from stronger/more flexible security,
> as envisaged in RADIUS over TLS. 

  How about this text:

Deployment experience with RADIUS over TLS indicates that is useful
for inter-server communication, such as inter-domain proxying across
the Internet.  The large amounts of traffic, and long-lived
connections are a good fit for TCP transport.  These situations
commonly also require complete data privacy that can be supplied by
TLS.

The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to
server communication is a bad fit, as there is usually insufficient
traffic to warrant the use of TCP.  Using "bare" TCP for inter-server
communication is a bad fit, as it provides for no data privacy.  The
only valid use-case for "bare" TCP, therefore, is on private, secured
networks where there is simultaneously a large amount of traffic, and
no need for data integrity or privacy.

  Alan DeKok.


  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 03:08:28 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3653A686B for ; Thu, 17 Sep 2009 03:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.924
X-Spam-Level: 
X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9wrvEeF-4zO for ; Thu, 17 Sep 2009 03:08:27 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 632473A6A5E for ; Thu, 17 Sep 2009 03:08:27 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoDsm-0000W3-79 for radiusext-data0@psg.com; Thu, 17 Sep 2009 10:06:32 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoDsb-0000V0-MB for radiusext@ops.ietf.org; Thu, 17 Sep 2009 10:06:29 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id E233E1234282; Thu, 17 Sep 2009 11:59:56 +0200 (CEST)
Message-ID: <4AB20A1C.906@deployingradius.com>
Date: Thu, 17 Sep 2009 12:06:20 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: Jari Arkko ,  "dromasca@avaya.com" , "Weber, Gregory D (Greg)" ,  "David B. Nelson" , 'radext mailing list' 
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
References:  <4A9D3578.6090908@deployingradius.com>   <4AAE26D4.9080607@piuha.net>  <4AB0B100.5000602@deployingradius.com> 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> As a result of the change, what will Section 2.2 look like?

  Updated text after the first paragraph below:


   Note that the Vendor type field in the recommended VSA format is only
   a single octet, like the RADIUS type field.  While this limitation
   results in an efficient encoding, there are situations in which a
   vendor or SDO will eventually wish to define more than 255
   attributes.  Also, an SDO can be comprised of multiple subgroups,
   each of whom can desire autonomy over the definition of attributes
   within their group.

   These desires have led vendors to define the following non-standard
   VSA formats:

   * Vendor types of 16 bits, followed by an 8 bit length and
     then attribute-specific data.

   * Vendor types of 32 bits, followed by no length field, and
     then attribute-specific data.

   * Vendor types of the RFC format, but where some VSAs are
     defined as "grouped" or TLV attributes.  These attributes
     are then used to carry sub-attributes.

   * "Bare" ASCII strings that immediately follow the Vendor-Id,
      without using a Vendor type or Vendor length.

   All of these formats are NOT RECOMMENDED.  All VSA formats that do
   not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
   RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
   lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
   Vendor-Specific contents that are not in Type-Length-Value format.

   Although [RFC2865] does not mandate it, implementations commonly
   assume that the Vendor Id can be used as a key to determine the on-
   the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
   formats for VSAs that are associated with a particular Vendor Id.  A
   vendor wishing to use multiple VSA formats, SHOULD request one Vendor
   Id for each VSA format that they will use.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 03:30:30 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647AA28C1E5 for ; Thu, 17 Sep 2009 03:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.642
X-Spam-Level: 
X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JHIG8YMjXZv for ; Thu, 17 Sep 2009 03:30:29 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA5573A6A51 for ; Thu, 17 Sep 2009 03:30:28 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoEDf-00034w-Mx for radiusext-data0@psg.com; Thu, 17 Sep 2009 10:28:07 +0000
Received: from [2001:14b8:400::130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoEDV-000337-3Q for radiusext@ops.ietf.org; Thu, 17 Sep 2009 10:28:05 +0000
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5FE2BD493C; Thu, 17 Sep 2009 13:27:56 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55RIQ8q0F0rd; Thu, 17 Sep 2009 13:27:55 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8ABFFD492B; Thu, 17 Sep 2009 13:27:55 +0300 (EEST)
Message-ID: <4AB20F2A.60003@piuha.net>
Date: Thu, 17 Sep 2009 13:27:54 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Alan DeKok 
CC: Bernard Aboba ,  "dromasca@avaya.com" , "Weber, Gregory D (Greg)" ,  "David B. Nelson" , 'radext mailing list' 
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
References:  <4A9D3578.6090908@deployingradius.com>   <4AAE26D4.9080607@piuha.net>  <4AB0B100.5000602@deployingradius.com>  <4AB20A1C.906@deployingradius.com>
In-Reply-To: <4AB20A1C.906@deployingradius.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

This resolves my Discuss.

But do you want to include a strong recommendation to not use these 
formats, if the plan is to shortly thereafter publish an update of the 
VSA base format to use 16 bits? Perhaps slightly weaker language would 
be better here. E.g., "These formats are currently NOT RECOMMENDED, 
though work is ongoing to possible update the current VSA format."

Jari

Alan DeKok wrote:
> Bernard Aboba wrote:
>   
>> As a result of the change, what will Section 2.2 look like?
>>     
>
>   Updated text after the first paragraph below:
>
>
>    Note that the Vendor type field in the recommended VSA format is only
>    a single octet, like the RADIUS type field.  While this limitation
>    results in an efficient encoding, there are situations in which a
>    vendor or SDO will eventually wish to define more than 255
>    attributes.  Also, an SDO can be comprised of multiple subgroups,
>    each of whom can desire autonomy over the definition of attributes
>    within their group.
>
>    These desires have led vendors to define the following non-standard
>    VSA formats:
>
>    * Vendor types of 16 bits, followed by an 8 bit length and
>      then attribute-specific data.
>
>    * Vendor types of 32 bits, followed by no length field, and
>      then attribute-specific data.
>
>    * Vendor types of the RFC format, but where some VSAs are
>      defined as "grouped" or TLV attributes.  These attributes
>      are then used to carry sub-attributes.
>
>    * "Bare" ASCII strings that immediately follow the Vendor-Id,
>       without using a Vendor type or Vendor length.
>
>    All of these formats are NOT RECOMMENDED.  All VSA formats that do
>    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
>    RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
>    lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
>    Vendor-Specific contents that are not in Type-Length-Value format.
>
>    Although [RFC2865] does not mandate it, implementations commonly
>    assume that the Vendor Id can be used as a key to determine the on-
>    the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
>    formats for VSAs that are associated with a particular Vendor Id.  A
>    vendor wishing to use multiple VSA formats, SHOULD request one Vendor
>    Id for each VSA format that they will use.
>
>   Alan DeKok.
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>
>   


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 05:11:50 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6B13A69DC for ; Thu, 17 Sep 2009 05:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBCuFu36N-Te for ; Thu, 17 Sep 2009 05:11:50 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C24A43A68A1 for ; Thu, 17 Sep 2009 05:11:49 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoFnL-000GAZ-H3 for radiusext-data0@psg.com; Thu, 17 Sep 2009 12:09:03 +0000
Received: from [198.152.13.100] (helo=co300216-co-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoFmk-000G4a-83 for radiusext@ops.ietf.org; Thu, 17 Sep 2009 12:08:44 +0000
X-IronPort-AV: E=Sophos;i="4.44,403,1249272000";  d="scan'208";a="183629317"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Sep 2009 08:08:24 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 17 Sep 2009 08:08:23 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 14:08:07 +0200
Message-ID: 
In-Reply-To: <4AB20F2A.60003@piuha.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Jari's DISCUSS on draft-ietf-radext-design-07.txt
thread-index: Aco3gYeW3QJ1aUVGTdiuPk2gsrbUSAADecZw
References:  <4A9D3578.6090908@deployingradius.com>   <4AAE26D4.9080607@piuha.net>  <4AB0B100.5000602@deployingradius.com>  <4AB20A1C.906@deployingradius.com> <4AB20F2A.60003@piuha.net>
From: "Romascanu, Dan (Dan)" 
To: "Jari Arkko" , "Alan DeKok" 
Cc: "Bernard Aboba" , "Weber, Gregory D (Greg)" , "David B. Nelson" , "radext mailing list" 
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

This looks acceptable to me.=20

Alan, do you plan to respin the I-D?=20

Thanks and Regards,

Dan
=20

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]=20
> Sent: Thursday, September 17, 2009 1:28 PM
> To: Alan DeKok
> Cc: Bernard Aboba; Romascanu, Dan (Dan); Weber, Gregory D=20
> (Greg); David B. Nelson; 'radext mailing list'
> Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
>=20
> This resolves my Discuss.
>=20
> But do you want to include a strong recommendation to not use=20
> these formats, if the plan is to shortly thereafter publish=20
> an update of the VSA base format to use 16 bits? Perhaps=20
> slightly weaker language would be better here. E.g., "These=20
> formats are currently NOT RECOMMENDED, though work is ongoing=20
> to possible update the current VSA format."
>=20
> Jari
>=20
> Alan DeKok wrote:
> > Bernard Aboba wrote:
> >  =20
> >> As a result of the change, what will Section 2.2 look like?
> >>    =20
> >
> >   Updated text after the first paragraph below:
> >
> >
> >    Note that the Vendor type field in the recommended VSA=20
> format is only
> >    a single octet, like the RADIUS type field.  While this=20
> limitation
> >    results in an efficient encoding, there are situations in which a
> >    vendor or SDO will eventually wish to define more than 255
> >    attributes.  Also, an SDO can be comprised of multiple subgroups,
> >    each of whom can desire autonomy over the definition of=20
> attributes
> >    within their group.
> >
> >    These desires have led vendors to define the following=20
> non-standard
> >    VSA formats:
> >
> >    * Vendor types of 16 bits, followed by an 8 bit length and
> >      then attribute-specific data.
> >
> >    * Vendor types of 32 bits, followed by no length field, and
> >      then attribute-specific data.
> >
> >    * Vendor types of the RFC format, but where some VSAs are
> >      defined as "grouped" or TLV attributes.  These attributes
> >      are then used to carry sub-attributes.
> >
> >    * "Bare" ASCII strings that immediately follow the Vendor-Id,
> >       without using a Vendor type or Vendor length.
> >
> >    All of these formats are NOT RECOMMENDED.  All VSA=20
> formats that do
> >    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
> >    RECOMMENDED formats include Vendor types of more than 8=20
> bits, Vendor
> >    lengths of less than 8 bits, Vendor lengths of more than=20
> 8 bits, and
> >    Vendor-Specific contents that are not in=20
> Type-Length-Value format.
> >
> >    Although [RFC2865] does not mandate it, implementations commonly
> >    assume that the Vendor Id can be used as a key to=20
> determine the on-
> >    the-wire format of a VSA.  Vendors therefore SHOULD NOT=20
> use multiple
> >    formats for VSAs that are associated with a particular=20
> Vendor Id.  A
> >    vendor wishing to use multiple VSA formats, SHOULD=20
> request one Vendor
> >    Id for each VSA format that they will use.
> >
> >   Alan DeKok.
> >
> > --
> > to unsubscribe send a message to=20
> radiusext-request@ops.ietf.org with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: 
> >
> >  =20
>=20
>=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 08:12:08 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586AA28C22F for ; Thu, 17 Sep 2009 08:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.908
X-Spam-Level: 
X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KWQe2C1PRlE for ; Thu, 17 Sep 2009 08:12:07 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E79928C23B for ; Thu, 17 Sep 2009 08:12:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoIaT-000Cca-7K for radiusext-data0@psg.com; Thu, 17 Sep 2009 15:07:57 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoIaB-000CZw-AK for radiusext@ops.ietf.org; Thu, 17 Sep 2009 15:07:52 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id E81DE1234282; Thu, 17 Sep 2009 17:01:19 +0200 (CEST)
Message-ID: <4AB250B7.4000804@deployingradius.com>
Date: Thu, 17 Sep 2009 17:07:35 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" 
CC: Jari Arkko ,  Bernard Aboba , "Weber, Gregory D (Greg)" ,  "David B. Nelson" , radext mailing list 
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
References:  <4A9D3578.6090908@deployingradius.com>   <4AAE26D4.9080607@piuha.net>  <4AB0B100.5000602@deployingradius.com>  <4AB20A1C.906@deployingradius.com> <4AB20F2A.60003@piuha.net> 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Romascanu, Dan (Dan) wrote:
> This looks acceptable to me. 
> 
> Alan, do you plan to respin the I-D? 

  Yes.  I can issue one tomorrow.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 08:48:02 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12383A697F for ; Thu, 17 Sep 2009 08:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.311
X-Spam-Level: *
X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQeWlEeHxBs7 for ; Thu, 17 Sep 2009 08:48:01 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27CC73A69CA for ; Thu, 17 Sep 2009 08:48:01 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoJAb-000HK2-PW for radiusext-data0@psg.com; Thu, 17 Sep 2009 15:45:17 +0000
Received: from [65.55.111.84] (helo=blu0-omc2-s9.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoJAR-000HIW-OV for radiusext@ops.ietf.org; Thu, 17 Sep 2009 15:45:15 +0000
Received: from BLU137-W20 ([65.55.111.71]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 08:45:07 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_ef2723cd-02b5-4019-9e50-c7be4368053d_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: REMINDER:  Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item
Date: Thu, 17 Sep 2009 08:45:07 -0700
Importance: Normal
In-Reply-To: <4AB204BE.3090305@deployingradius.com>
References:  <4AA6C0B2.8040404@venaas.com>  <4AB204BE.3090305@deployingradius.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Sep 2009 15:45:07.0023 (UTC) FILETIME=[D4A985F0:01CA37AD]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_ef2723cd-02b5-4019-9e50-c7be4368053d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Deployment experience with RADIUS over TLS indicates that is useful
> for inter-server communication=2C such as inter-domain proxying across
> the Internet.  The large amounts of traffic=2C and long-lived
> connections are a good fit for TCP transport.  These situations
> commonly also require complete data privacy that can be supplied by
> TLS.
>=20
> The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to
> server communication is a bad fit=2C as there is usually insufficient
> traffic to warrant the use of TCP.  Using "bare" TCP for inter-server
> communication is a bad fit=2C as it provides for no data privacy.  The
> only valid use-case for "bare" TCP=2C therefore=2C is on private=2C secur=
ed
> networks where there is simultaneously a large amount of traffic=2C and
> no need for data integrity or privacy.


How about this?=20



"Deployment experience with RADIUS over TLS indicates that it is=20

most useful for inter-server communication=2C such as inter-domain
communication between proxies.  These situations benefit from
the confidentiality and ciphersuite negotiation that can be provided=20
by TLS. Since TLS is already widely available within the operating=20
systems used by proxies=2C implementation barriers are low.=20

RADIUS over TCP has a similar set of use cases.  Use of TCP as
a transport between a NAS and RADIUS server is a poor fit=2C
since as noted in [RFC3539]=2C there is likely to be insufficient traffic f=
or=20
the congestion window to remain above the minimum value on a
long-term basis.  The result is an increase in packets due to ACKs=20
as compared to UDP=2C without a corresponding set of benefits.=20

In server-server communications the traffic levels in both
directions are typically high enough to support a larger
congestion window as well as ACK piggy-backing. =20
Through use of an application-layer watchdog as described
in [RFC3539]=2C it is possible to address the objections
to reliable transport described in [RFC2865] Section 2.4.=20
However=2C in these scenarios "bare" TCP does not provide for=20
confidentiality or enable negotiation of stronger ciphersuites
than are available in RADIUS.=20

As a result of these considerations=2C use of RADIUS over
TCP SHOULD be restricted to situations where RADIUS over
TLS is employed.  RADIUS over "bare" TCP is NOT RECOMMENDED."

--_ef2723cd-02b5-4019-9e50-c7be4368053d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B Deployment experience with RADIUS over TLS indicates that is useful<=
br>>=3B for inter-server communication=2C such as inter-domain proxying a=
cross
>=3B the Internet.  The large amounts of traffic=2C and long-liv=
ed
>=3B connections are a good fit for TCP transport.  These situation=
s
>=3B commonly also require complete data privacy that can be supplie=
d by
>=3B TLS.
>=3B 
>=3B The use of "bare" TCP has fewer us=
e-cases.  Using TCP for NAS to
>=3B server communication is a bad fit=
=2C as there is usually insufficient
>=3B traffic to warrant the use o=
f TCP.  Using "bare" TCP for inter-server
>=3B communication is a bad =
fit=2C as it provides for no data privacy.  The
>=3B only valid use-ca=
se for "bare" TCP=2C therefore=2C is on private=2C secured
>=3B networ=
ks where there is simultaneously a large amount of traffic=2C and
>=3B=
 no need for data integrity or privacy.


How about this? 



"Deployment experience with RADIUS over TLS indicates that it is 

most useful for inter-server communication=2C such as inter-domain
commu=
nication between proxies. =3B These situations benefit from
the conf=
identiality and ciphersuite negotiation that can be provided 
by TLS. Si=
nce TLS is already widely available within the operating 
systems used b=
y proxies=2C implementation barriers are low. 

RADIUS over TCP has a=
 similar set of use cases. =3B Use of TCP as
a transport between a N=
AS and RADIUS server is a poor fit=2C
since as noted in [RFC3539]=2C the=
re is likely to be insufficient traffic for 
the congestion window to re=
main above the minimum value on a
long-term basis. =3B The result is=
 an increase in packets due to ACKs 
as compared to UDP=2C without a cor=
responding set of benefits. 

In server-server communications the tra=
ffic levels in both
directions are typically high enough to support a la=
rger
congestion window as well as ACK piggy-backing. =3B 
Through=
 use of an application-layer watchdog as described
in [RFC3539]=2C it is=
 possible to address the objections
to reliable transport described in [=
RFC2865] Section 2.4. 
However=2C in these scenarios "bare" TCP does not=
 provide for 
confidentiality or enable negotiation of stronger ciphersu=
ites
than are available in RADIUS. 

As a result of these consider=
ations=2C use of RADIUS over
TCP SHOULD be restricted to situations wher=
e RADIUS over
TLS is employed. =3B RADIUS over "bare" TCP is NOT REC=
OMMENDED."

=

--_ef2723cd-02b5-4019-9e50-c7be4368053d_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 08:53:01 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1A23A6864 for ; Thu, 17 Sep 2009 08:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.11
X-Spam-Level: 
X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq0iBLSDaARD for ; Thu, 17 Sep 2009 08:53:00 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BD103A697F for ; Thu, 17 Sep 2009 08:53:00 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoJGT-000I8u-Gl for radiusext-data0@psg.com; Thu, 17 Sep 2009 15:51:21 +0000
Received: from [65.55.111.76] (helo=blu0-omc2-s1.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoJGI-000I6Y-V5 for radiusext@ops.ietf.org; Thu, 17 Sep 2009 15:51:18 +0000
Received: from BLU137-W36 ([65.55.111.72]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 08:51:10 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_939f895e-c564-4eec-b908-939ab189ece1_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Alan DeKok 
CC: Jari Arkko , "dromasca@avaya.com" , , "David B. Nelson" , "radiusext@ops.ietf.org" 
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 08:51:10 -0700
Importance: Normal
In-Reply-To: <4AB20A1C.906@deployingradius.com>
References:  <4A9D3578.6090908@deployingradius.com>   <4AAE26D4.9080607@piuha.net>  <4AB0B100.5000602@deployingradius.com>  <4AB20A1C.906@deployingradius.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Sep 2009 15:51:10.0753 (UTC) FILETIME=[AD765110:01CA37AE]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_939f895e-c564-4eec-b908-939ab189ece1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>    All of these formats are NOT RECOMMENDED.  All VSA formats that do
>    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
>    RECOMMENDED formats include Vendor types of more than 8 bits=2C Vendor
>    lengths of less than 8 bits=2C Vendor lengths of more than 8 bits=2C a=
nd
>    Vendor-Specific contents that are not in Type-Length-Value format.

How about this?=20

All VSA schemes that do not follow the [RFC2865] recommendations
are NOT RECOMMENDED since these formats will typically not be
implementable without RADIUS server code changes.  This includes all=20
the above formats=2C as well as Vendor types of more than 8 bits=2C vendor=
=20
lengths of less than 8 bits=2C vendor lengths of more than 8 bits and=20
Vendor-Specific contents that are not in Type-Length-Value format.=20

--_939f895e-c564-4eec-b908-939ab189ece1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B    All of these formats are NOT RECOMMENDED.  All VSA formats that d=
o
>=3B    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT>=3B    RECOMMENDED formats include Vendor types of more than 8 bits=2C=
 Vendor
>=3B    lengths of less than 8 bits=2C Vendor lengths of more =
than 8 bits=2C and
>=3B    Vendor-Specific contents that are not in Ty=
pe-Length-Value format.

How about this? 

All VSA schemes that=
 do not follow the [RFC2865] recommendations
are NOT RECOMMENDED since t=
hese formats will typically not be
implementable without RADIUS server c=
ode changes. =3B This includes all 
the above formats=2C as well as =
Vendor types of more than 8 bits=2C vendor 
lengths of less than 8 bits=
=2C vendor lengths of more than 8 bits and 
Vendor-Specific contents tha=
t are not in Type-Length-Value format. 

=

--_939f895e-c564-4eec-b908-939ab189ece1_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 17 08:56:29 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A9D3A6899 for ; Thu, 17 Sep 2009 08:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.104
X-Spam-Level: 
X-Spam-Status: No, score=0.104 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-iuaGFzX0SP for ; Thu, 17 Sep 2009 08:56:28 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E1883A6834 for ; Thu, 17 Sep 2009 08:56:28 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoJJJ-000IXV-QW for radiusext-data0@psg.com; Thu, 17 Sep 2009 15:54:17 +0000
Received: from [65.55.111.113] (helo=blu0-omc2-s38.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MoJJA-000IWX-Ca for radiusext@ops.ietf.org; Thu, 17 Sep 2009 15:54:15 +0000
Received: from BLU137-W37 ([65.55.111.73]) by blu0-omc2-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 08:54:08 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Alan DeKok 
CC: Jari Arkko , "dromasca@avaya.com" , , "David B. Nelson" , "radiusext@ops.ietf.org" 
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 08:54:08 -0700
Importance: Normal
In-Reply-To: <4AB20A1C.906@deployingradius.com>
References:  <4A9D3578.6090908@deployingradius.com>   <4AAE26D4.9080607@piuha.net>  <4AB0B100.5000602@deployingradius.com>  <4AB20A1C.906@deployingradius.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Sep 2009 15:54:08.0301 (UTC) FILETIME=[1749FDD0:01CA37AF]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>    Note that the Vendor type field in the recommended VSA format is only
>    a single octet=2C like the RADIUS type field.  While this limitation
>    results in an efficient encoding=2C there are situations in which a
>    vendor or SDO will eventually wish to define more than 255
>    attributes.  Also=2C an SDO can be comprised of multiple subgroups=2C
>    each of whom can desire autonomy over the definition of attributes
>    within their group.
>=20
>    These desires have led vendors to define the following non-standard
>    VSA formats:

How about this?

"Note that the Vendor type field in the recommended VSA format is only
a single octet=2C like the RADIUS type field.  While this limitation
results in an efficient encoding=2C there are situations in which a
vendor or SDO will eventually wish to define more than 255
attributes.  Also=2C an SDO can be comprised of multiple subgroups=2C
each of whom can desire autonomy over the definition of attributes
within their group.  The most interoperable way to address these
issues is for the vendor or SDO to request allocation of multiple
Vendor identifiers.=20

However=2C instead of doing this=2C vendors have defined the following
non-standard VSA formats:"

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B    Note that the Vendor type field in the recommended VSA format is =
only
>=3B    a single octet=2C like the RADIUS type field.  While this=
 limitation
>=3B    results in an efficient encoding=2C there are situ=
ations in which a
>=3B    vendor or SDO will eventually wish to define=
 more than 255
>=3B    attributes.  Also=2C an SDO can be comprised of=
 multiple subgroups=2C
>=3B    each of whom can desire autonomy over t=
he definition of attributes
>=3B    within their group.
>=3B 
=
>=3B    These desires have led vendors to define the following non-standa=
rd
>=3B    VSA formats:

How about this?

"Note that the V=
endor type field in the recommended VSA format is only
a single octet=2C=
 like the RADIUS type field.  While this limitation
results in an effici=
ent encoding=2C there are situations in which a
vendor or SDO will event=
ually wish to define more than 255
attributes.  Also=2C an SDO can be co=
mprised of multiple subgroups=2C
each of whom can desire autonomy over t=
he definition of attributes
within their group. =3B The most interop=
erable way to address these
issues is for the vendor or SDO to request a=
llocation of multiple
Vendor identifiers. 

However=2C instead of =
doing this=2C vendors have defined the following
non-standard VSA format=
s:"

=

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Wed Sep 23 03:50:10 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258973A62C1 for ; Wed, 23 Sep 2009 03:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.372
X-Spam-Level: 
X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXxVtLVol3uT for ; Wed, 23 Sep 2009 03:50:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 164CE3A672E for ; Wed, 23 Sep 2009 03:50:09 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MqPOB-000L5x-Fq for radiusext-data0@psg.com; Wed, 23 Sep 2009 10:47:59 +0000
Received: from [192.160.6.148] (helo=hoemail1.alcatel.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MqPO1-000L4l-RS for radiusext@ops.ietf.org; Wed, 23 Sep 2009 10:47:57 +0000
Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id n8NAlfq7023492; Wed, 23 Sep 2009 05:47:41 -0500 (CDT)
Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id n8NAldbI024236; Wed, 23 Sep 2009 05:47:40 -0500 (CDT)
Received: from sgsinsbhs02.ad4.ad.alcatel.com (sgsinsbhs02.ap.lucent.com [135.254.109.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n8NAbwUh024351; Wed, 23 Sep 2009 18:37:58 +0800
Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.30]) by sgsinsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 18:47:35 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: IPv6 Address Option
Date: Wed, 23 Sep 2009 18:47:34 +0800
Message-ID: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPv6 Address Option
Thread-Index: Aco8O0FDrpRBcz7QSkaHOfeWkXrtAQ==
From: "MILES DAVID" 
To: , , 
Cc: "Maglione Roberta" , 
X-OriginalArrivalTime: 23 Sep 2009 10:47:35.0137 (UTC) FILETIME=[42966510:01CA3C3B]
X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27
X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Folk,

A few months back some of us expressed a desire to proceed with the
draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
item. In the recent Broadband Forum meeting in Tokyo it was announced
that the BBF will seek to finalize their document on IPv6 for PPP
environments (to which I am co-editor). With the lack of some essential
RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
a hard place.

Delaying the IPv6 for PPP document much beyond November is not an option
for a large number of operators who wish to get some IPv6 deployment
going. With this goal in mind I ask the WG and chairs to adopt this
draft as a starting point with a goal of getting to WGLC within the
coming months (after Hiroshima IETF). If it needs to be simplified down
to the essential AVP I am happy to work with the current authors to
create a draft which can be fast tracked.

The alternatives are ugly IMO


Regards

-David Miles

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Thu Sep 24 14:31:49 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBEF3A6774 for ; Thu, 24 Sep 2009 14:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.821
X-Spam-Level: 
X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKWAZ68dn2-V for ; Thu, 24 Sep 2009 14:31:48 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDF1E3A68B9 for ; Thu, 24 Sep 2009 14:31:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mqvsd-0009wy-28 for radiusext-data0@psg.com; Thu, 24 Sep 2009 21:29:35 +0000
Received: from [65.55.116.36] (helo=blu0-omc1-s25.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MqvsQ-0009tE-Jk for radiusext@ops.ietf.org; Thu, 24 Sep 2009 21:29:32 +0000
Received: from BLU137-W9 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Sep 2009 14:29:22 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_315b0f9e-25cb-427c-92e0-dfd18f076caf_"
X-Originating-IP: [131.107.0.103]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG Virtual Interim Agenda:  October 13, 2009
Date: Thu, 24 Sep 2009 14:29:22 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Sep 2009 21:29:22.0443 (UTC) FILETIME=[1524BDB0:01CA3D5E]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




Agenda
Meeting agenda is available here:=20
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt

Slides
Slides are available for download here:=20
http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/

AUDIO INFORMATION=20

To
join a meeting from your phone=2C dial in using the following information:

            Phone:   +18883203585 [English]

            Phone:   +14257063500 [English]

            Find a local
phone number for your region

=20

            Conference ID:    9182049

            Passcode:           Passcode is not required.

            Note: If you have an account on this
corporate network=2C use your PIN to join. Have you set
your PIN?
Web Conferencing information (optional)
To join the online meeting=2C click on the following URL:=20

Join the meeting

 To install the Office Live Meeting client click here.=20

TROUBLESHOOTING=20

Unable
to join the meeting?  Start Office Live
Meeting and join the meeting with the following information:

            Meeting ID:        63840ffb128647eca56d51898b461c42

            Entry Code:        6650

            Location:            meet:sip:bernarda@microsoft.com=3Bgruu=3Bo=
paque=3Dapp:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf-key=3D665=
0

=20

If
you still cannot enter the meeting=2C contact support:=20



Live Meeting Support



 		 	   		  =

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






=



Agenda

Meeting agenda is available here: 
http://www.drizzle.com/~aboba/RA=
DEXT/oct-virtual-interim.txt
<=
/span>
<=
span style=3D"font-family: "=3BTahoma"=3B=2C"=3Bsans-serif"=
=3B=3B color: rgb(0=2C 77=2C 128)=3B">
Slides

S=
lides are available for download here: 
http://www.drizzle.com/~aboba/RADEXT/oct_virtu=
al_interim/

AUDIO INFOR=
MATION 



To
join a meeting from your phone=2C dial in using the following information:<=
o:p>



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Phone: =
=3B =3B +18883203585 [English]



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Phone: =
=3B =3B +14257063500 [English]



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Find a local
phone number for your region



 =3B



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Conference ID: =3B =3B =3B 9182049



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Passcode:&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3B =3B =
=3B Passcode is not required.



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Note: If you have an account =
on this
corporate network=2C use your PIN to join. Have you set
your PIN?

<=
/p>
Web Conferencing information (optional)<=
/b>

To join the online=
 meeting=2C click on the following URL: 



Join the meeting



 =3B
To install=
 the Office Live Meeting client click here. 

=

TROUBLESHOOTING 



Unable
to join the meeting? =3B Start Office Live
Meeting and join the meeting with the following information:



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Meeting ID:&=
nbsp=3B =3B =3B =3B =3B =3B =3B 63840ffb1286=
47eca56d51898b461c42



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Entry Code:&=
nbsp=3B =3B =3B =3B =3B =3B =3B 6650



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Location:&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3B =3B =
=3B =3B =
meet:sip:bernarda@microsoft.com=3Bgruu=3Bopaque=3Dapp:conf:focus:id:63840ff=
b128647eca56d51898b461c42%3Fconf-key=3D6650



 =3B



If
you still cannot enter the meeting=2C contact support: 




Live Meeting Support<=
/span>





 		 	   		  
=

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 00:19:48 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF8528C0E3 for ; Sat, 26 Sep 2009 00:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.169
X-Spam-Level: 
X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3WEpDd0CNsq for ; Sat, 26 Sep 2009 00:19:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 558EC3A68A1 for ; Sat, 26 Sep 2009 00:19:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrRWo-000G9A-Fb for radiusext-data0@psg.com; Sat, 26 Sep 2009 07:17:10 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrRWb-000G84-34 for radiusext@ops.ietf.org; Sat, 26 Sep 2009 07:17:08 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id C894A1234491; Sat, 26 Sep 2009 09:16:09 +0200 (CEST)
Message-ID: <4ABDBFE5.4050406@deployingradius.com>
Date: Sat, 26 Sep 2009 09:16:53 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: MILES DAVID 
CC: radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  Maglione Roberta , townsley@cisco.com
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>
In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

  Is there a response to my review?

http://ops.ietf.org/lists/radiusext/2009/msg00401.html

  Addressing the minor issues brought up in the review would allow
server implementations to support the document by simply updating their
dictionaries.  As it stands now, new data types will have to be defined,
which can be a significant barrier to adoption.

MILES DAVID wrote:
> Folk,
> 
> A few months back some of us expressed a desire to proceed with the
> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
> item. In the recent Broadband Forum meeting in Tokyo it was announced
> that the BBF will seek to finalize their document on IPv6 for PPP
> environments (to which I am co-editor). With the lack of some essential
> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
> a hard place.
> 
> Delaying the IPv6 for PPP document much beyond November is not an option
> for a large number of operators who wish to get some IPv6 deployment
> going. With this goal in mind I ask the WG and chairs to adopt this
> draft as a starting point with a goal of getting to WGLC within the
> coming months (after Hiroshima IETF). If it needs to be simplified down
> to the essential AVP I am happy to work with the current authors to
> create a draft which can be fast tracked.
> 
> The alternatives are ugly IMO
> 
> 
> Regards
> 
> -David Miles
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
> 
> 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 02:57:33 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCB03A67AC for ; Sat, 26 Sep 2009 02:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Level: 
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nQKrRCylkmb for ; Sat, 26 Sep 2009 02:57:32 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE0533A63CB for ; Sat, 26 Sep 2009 02:57:32 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrTzG-0004WI-UH for radiusext-data0@psg.com; Sat, 26 Sep 2009 09:54:42 +0000
Received: from [76.96.59.243] (helo=QMTA13.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrTz3-0004UA-QI for radiusext@ops.ietf.org; Sat, 26 Sep 2009 09:54:40 +0000
Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA13.westchester.pa.mail.comcast.net with comcast id lMra1c0011ZXKqc5DMuV2W; Sat, 26 Sep 2009 09:54:29 +0000
Received: from gwzPC ([124.122.164.146]) by OMTA21.westchester.pa.mail.comcast.net with comcast id lMzH1c00E39q3ZG3hMzMZA; Sat, 26 Sep 2009 09:59:42 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" , "'MILES DAVID'" 
Cc: , , , "'Maglione Roberta'" , 
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com>
In-Reply-To: <4ABDBFE5.4050406@deployingradius.com>
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 16:53:34 +0700
Message-ID: <000301ca3e8f$46331a00$d2994e00$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco+ed/JwFhVVLTOTAO3awmb7omv2gACINUQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok [mailto://aland@deployingradius.com] writes:

>   Is there a response to my review?
> 
> http://ops.ietf.org/lists/radiusext/2009/msg00401.html
> 
>   Addressing the minor issues brought up in the review would allow
> server implementations to support the document by simply updating their
> dictionaries.  As it stands now, new data types will have to be
> defined,
> which can be a significant barrier to adoption.

In your review you say "Defining a tag field *and* a 32-bit integer means
that you're
re-defining the meaning of a tag + integer attribute.  See RFC 2868, Section
3.1 for the historical definition. It would seem to be OK to have a 24-bit
lifetime.  That would allow everyone to use this attribute by simply
updating their dictionaries, rather than writing new code to handle a new
format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking about
the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT use
this tagging method...".  Which is it?  

...


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 03:11:31 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAA33A682F for ; Sat, 26 Sep 2009 03:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Level: 
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsElt0-6BwUQ for ; Sat, 26 Sep 2009 03:11:30 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6FA73A67A8 for ; Sat, 26 Sep 2009 03:11:30 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrUE5-0005xo-51 for radiusext-data0@psg.com; Sat, 26 Sep 2009 10:10:01 +0000
Received: from [76.96.27.243] (helo=QMTA13.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrUDu-0005wp-GM for radiusext@ops.ietf.org; Sat, 26 Sep 2009 10:09:59 +0000
Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id lN9r1c0060FhH24ADN9rWV; Sat, 26 Sep 2009 10:09:51 +0000
Received: from gwzPC ([124.122.164.146]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id lN9P1c00239q3ZG8UN9T8G; Sat, 26 Sep 2009 10:09:49 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" , "'MILES DAVID'" 
Cc: , , , "'Maglione Roberta'" , 
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net>
In-Reply-To: <000301ca3e8f$46331a00$d2994e00$@net>
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 17:08:56 +0700
Message-ID: <000401ca3e91$6b916070$42b42150$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco+ed/JwFhVVLTOTAO3awmb7omv2gACINUQAAOSq0A=
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

I wrote:

> Alan DeKok [mailto://aland@deployingradius.com] writes:
> 
> >   Is there a response to my review?
> >
> > http://ops.ietf.org/lists/radiusext/2009/msg00401.html
> >
> >   Addressing the minor issues brought up in the review would allow
> > server implementations to support the document by simply updating
> their
> > dictionaries.  As it stands now, new data types will have to be
> > defined,
> > which can be a significant barrier to adoption.
> 
> In your review you say "Defining a tag field *and* a 32-bit integer
> means
> that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section
> 3.1 for the historical definition. It would seem to be OK to have a 24-
> bit
> lifetime.  That would allow everyone to use this attribute by simply
> updating their dictionaries, rather than writing new code to handle a
> new
> format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking
> about
> the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT
> use
> this tagging method...".  Which is it?

Even more interestingly, your latest missive seems to strongly imply that
adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
to adoption" of new attributes designed following them...




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 03:42:12 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CEA3A6824 for ; Sat, 26 Sep 2009 03:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOJXsE1ONyJY for ; Sat, 26 Sep 2009 03:42:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DE7C3A67BE for ; Sat, 26 Sep 2009 03:42:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrUhY-0008M5-Ll for radiusext-data0@psg.com; Sat, 26 Sep 2009 10:40:28 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrUhP-0008LS-BL for radiusext@ops.ietf.org; Sat, 26 Sep 2009 10:40:26 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 722111234491; Sat, 26 Sep 2009 12:39:38 +0200 (CEST)
Message-ID: <4ABDEF91.5080701@deployingradius.com>
Date: Sat, 26 Sep 2009 12:40:17 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net>
In-Reply-To: <000301ca3e8f$46331a00$d2994e00$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> ... but draft-ietf-radext-design-08, section 2.1.2 says (talking about
> the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT use
> this tagging method...".  Which is it?  

  I suggest racing against the design guidelines document.  After all,
it's only a draft.  If the IPv6 document can get published first, then
the design guidelines matter a lot less.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 03:52:48 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1B23A6864 for ; Sat, 26 Sep 2009 03:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level: 
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmdkejinNlcM for ; Sat, 26 Sep 2009 03:52:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E2C83A6853 for ; Sat, 26 Sep 2009 03:52:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrUsC-0009H9-UR for radiusext-data0@psg.com; Sat, 26 Sep 2009 10:51:28 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrUs2-0009GV-7q for radiusext@ops.ietf.org; Sat, 26 Sep 2009 10:51:25 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id E015A1234491; Sat, 26 Sep 2009 12:50:37 +0200 (CEST)
Message-ID: <4ABDF224.9070307@deployingradius.com>
Date: Sat, 26 Sep 2009 12:51:16 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net> <000401ca3e91$6b916070$42b42150$@net>
In-Reply-To: <000401ca3e91$6b916070$42b42150$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Even more interestingly, your latest missive seems to strongly imply that
> adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
> to adoption" of new attributes designed following them...

  Perhaps there's an IETF process to obtain WG consensus and update
published documents?

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 06:14:12 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9743A6868 for ; Sat, 26 Sep 2009 06:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Level: 
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwBunpi7eacU for ; Sat, 26 Sep 2009 06:14:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EC873A685F for ; Sat, 26 Sep 2009 06:14:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrX2X-000MQu-LB for radiusext-data0@psg.com; Sat, 26 Sep 2009 13:10:17 +0000
Received: from [76.96.27.243] (helo=QMTA13.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrX2O-000MP8-8P for radiusext@ops.ietf.org; Sat, 26 Sep 2009 13:10:15 +0000
Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id lR871c0040EPchoADRA8DD; Sat, 26 Sep 2009 13:10:08 +0000
Received: from gwzPC ([124.122.164.146]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id lR9f1c00239q3ZG8MR9jTD; Sat, 26 Sep 2009 13:10:06 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'MILES DAVID'" , , , , "'Maglione Roberta'" , 
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net> <000401ca3e91$6b916070$42b42150$@net> <4ABDF224.9070307@deployingradius.com>
In-Reply-To: <4ABDF224.9070307@deployingradius.com>
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 20:09:11 +0700
Message-ID: <000b01ca3eaa$9af96b00$d0ec4100$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco+l0hzmeJwAV8GT7uZdad8Ro+aPgAEyg8A
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Even more interestingly, your latest missive seems to strongly imply
> that
> > adopting the RADIUS Design (Mis-)Guidelines will be a "significant
> barrier
> > to adoption" of new attributes designed following them...
> 
>   Perhaps there's an IETF process to obtain WG consensus and update
> published documents?

What do you mean?



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 07:28:59 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8CB3A687E for ; Sat, 26 Sep 2009 07:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8DM5+eqrcWN for ; Sat, 26 Sep 2009 07:28:58 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE6643A6801 for ; Sat, 26 Sep 2009 07:28:57 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrYF9-0006uj-7c for radiusext-data0@psg.com; Sat, 26 Sep 2009 14:27:23 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrYEz-0006tC-SW for radiusext@ops.ietf.org; Sat, 26 Sep 2009 14:27:21 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id E5C791234491; Sat, 26 Sep 2009 16:26:36 +0200 (CEST)
Message-ID: <4ABE24BE.20604@deployingradius.com>
Date: Sat, 26 Sep 2009 16:27:10 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net> <000401ca3e91$6b916070$42b42150$@net> <4ABDF224.9070307@deployingradius.com> <000b01ca3eaa$9af96b00$d0ec4100$@net>
In-Reply-To: <000b01ca3eaa$9af96b00$d0ec4100$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
> 
>> Glen Zorn wrote:
>>> Even more interestingly, your latest missive seems to strongly imply
>> that
>>> adopting the RADIUS Design (Mis-)Guidelines will be a "significant
>> barrier
>>> to adoption" of new attributes designed following them...
>>   Perhaps there's an IETF process to obtain WG consensus and update
>> published documents?
> 
> What do you mean?

  Later documents can update earlier documents.  If the design
guidelines is as catastrophic as you claim, later documents can update
it, and define new attributes that don't follow it's recommendations.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 17:24:10 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE01A3A6846 for ; Sat, 26 Sep 2009 17:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.361
X-Spam-Level: *
X-Spam-Status: No, score=1.361 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx1dBckTeYoI for ; Sat, 26 Sep 2009 17:24:10 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6FB93A67D7 for ; Sat, 26 Sep 2009 17:24:09 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrhWE-0009o4-Ax for radiusext-data0@psg.com; Sun, 27 Sep 2009 00:21:38 +0000
Received: from [65.55.116.47] (helo=blu0-omc1-s36.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrhW4-0009mM-Hb for radiusext@ops.ietf.org; Sun, 27 Sep 2009 00:21:35 +0000
Received: from BLU137-W3 ([65.55.116.7]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 17:21:28 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: , "radiusext@ops.ietf.org" , "David B. Nelson" 
CC: , Mark Townsley 
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 17:21:27 -0700
Importance: Normal
In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Sep 2009 00:21:28.0169 (UTC) FILETIME=[7494FD90:01CA3F08]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> A few months back some of us expressed a desire to proceed with the
> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
> item.=20

On June 25=2C 2009 there was a WG call for interest in the document:=20
http://ops.ietf.org/lists/radiusext/2009/msg00273.html

Only one person other than yourself and the authors replied to the call for=
 interest.=20

In addition=2C the document has not been revised in response to WG comments=
.=20

> In the recent Broadband Forum meeting in Tokyo it was announced
> that the BBF will seek to finalize their document on IPv6 for PPP
> environments (to which I am co-editor). With the lack of some essential
> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
> a hard place.

If there was interest from the Broadband Forum=2C why has noone bothered to
respond to the call for interest or to revise the document?=20

> Delaying the IPv6 for PPP document much beyond November is not an option

If that is the case=2C why are the concerned parties not doing more to move=
 it forward?=20

> I am happy to work with the current authors to create a draft which can b=
e fast tracked.

If you're volunteering to act as editor=2C that would be great.  Next step =
would be to issue a=20
version of the document addressing outstanding comments.  We can then discu=
ss the=20
document at the October 13 Virtual Interim meeting.=20

 		 	   		  =

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B A few months back some of us expressed a desire to proceed with the<=
br>>=3B draft-lourdelet-radext-ipv6-access-01 and recommend its adoption =
as a WG
>=3B item. 

On June 25=2C 2009 there was a WG call for =
interest in the document: 
http://ops.ietf.org/lists/radiusext/2009/msg0=
0273.html

Only one person other than yourself and the authors replie=
d to the call for interest. 

In addition=2C the document has not bee=
n revised in response to WG comments. 

>=3B In the recent Broadban=
d Forum meeting in Tokyo it was announced
>=3B that the BBF will seek =
to finalize their document on IPv6 for PPP
>=3B environments (to which=
 I am co-editor). With the lack of some essential
>=3B RADIUS AVP (suc=
h as IPv6-Address-Option) we are stuck between a rock and
>=3B a hard =
place.

If there was interest from the Broadband Forum=2C why has noo=
ne bothered to
respond to the call for interest or to revise the documen=
t? 

>=3B Delaying the IPv6 for PPP document much beyond November i=
s not an option

If that is the case=2C why are the concerned parties=
 not doing more to move it forward? 

>=3B I am happy to work with =
the current authors to create a draft which can be fast tracked.

If =
you're volunteering to act as editor=2C that would be great. =3B Next s=
tep would be to issue a 
version of the document addressing outstanding =
comments. =3B We can then discuss the 
document at the October 13 Vi=
rtual Interim meeting. 

 		 	   		  
=

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 20:31:59 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C834F3A681C for ; Sat, 26 Sep 2009 20:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.977
X-Spam-Level: *
X-Spam-Status: No, score=1.977 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haVUXjPt+sEx for ; Sat, 26 Sep 2009 20:31:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B00AA3A6812 for ; Sat, 26 Sep 2009 20:31:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrkRh-000Och-7n for radiusext-data0@psg.com; Sun, 27 Sep 2009 03:29:09 +0000
Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrkRX-000ObQ-Rp for radiusext@ops.ietf.org; Sun, 27 Sep 2009 03:29:07 +0000
Received: from OMTA18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id lf8n1c0041bwxycA1fUGJ0; Sun, 27 Sep 2009 03:28:16 +0000
Received: from gwzPC ([124.121.210.34]) by OMTA18.emeryville.ca.mail.comcast.net with comcast id lfZV1c0020l4j3Q8efZcpw; Sun, 27 Sep 2009 03:34:21 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'MILES DAVID'" , , , , "'Maglione Roberta'" , 
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net> <4ABDEF91.5080701@deployingradius.com>
In-Reply-To: <4ABDEF91.5080701@deployingradius.com>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 10:27:37 +0700
Message-ID: <001f01ca3f22$96537410$c2fa5c30$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco+lcBAQ4JbpIirToyCaK9ergH6LgAFM1CQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > ... but draft-ietf-radext-design-08, section 2.1.2 says (talking
> about
> > the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT
> use
> > this tagging method...".  Which is it?
> 
>   I suggest racing against the design guidelines document.  

What a great idea!  Since the Mis-Guidelines draft is in IESG evaluation &
our draft has yet to be accepted as a WG item, it's a race we're sure to
win!  A more likely scenario: we change our draft to match your "review",
then the Mis-Guidelines draft is published as an ACP (Alan's Current
Practice) & presto, we get to change it again.  It would be a classic of
obstructionism, if only it weren't so obvious.

> After all, it's only a draft.  

Hmm.  That didn't seem to be relevant when you used it a club (its real
purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

...



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 22:36:44 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8D33A692A for ; Sat, 26 Sep 2009 22:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.514
X-Spam-Level: *
X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNqrNg9uw-z9 for ; Sat, 26 Sep 2009 22:36:44 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C70A93A6926 for ; Sat, 26 Sep 2009 22:36:43 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrmOR-000CeQ-Q2 for radiusext-data0@psg.com; Sun, 27 Sep 2009 05:33:55 +0000
Received: from [76.96.30.64] (helo=QMTA07.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrmOI-000CdZ-88 for radiusext@ops.ietf.org; Sun, 27 Sep 2009 05:33:53 +0000
Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id lhXM1c0051HpZEsA7hZmBF; Sun, 27 Sep 2009 05:33:46 +0000
Received: from gwzPC ([124.121.210.34]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id lhYp1c0040l4j3Q8ahYwzE; Sun, 27 Sep 2009 05:33:41 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'MILES DAVID'" , , , , "'Maglione Roberta'" , 
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net> <000401ca3e91$6b916070$42b42150$@net> <4ABDF224.9070307@deployingradius.com> <000b01ca3eaa$9af96b00$d0ec4100$@net> <4ABE24BE.20604@deployingradius.com>
In-Reply-To: <4ABE24BE.20604@deployingradius.com>
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 12:32:24 +0700
Message-ID: <004801ca3f34$03f249e0$0bd6dda0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco+tXLUuzshFtPySEyfgZg2ujcYegAfgkdQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto:aland@deployingradius.com] writes:
> >
> >> Glen Zorn wrote:
> >>> Even more interestingly, your latest missive seems to strongly
> imply
> >> that
> >>> adopting the RADIUS Design (Mis-)Guidelines will be a "significant
> >> barrier
> >>> to adoption" of new attributes designed following them...
> >>   Perhaps there's an IETF process to obtain WG consensus and update
> >> published documents?
> >
> > What do you mean?
> 
>   Later documents can update earlier documents.  If the design
> guidelines is as catastrophic as you claim, 

Actually, _you_ made the claim, I just quoted it.

> later documents can update
> it, and define new attributes that don't follow it's recommendations.
> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 23:41:42 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71CA3A6405 for ; Sat, 26 Sep 2009 23:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.076
X-Spam-Level: 
X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BkfS-I1y5EM for ; Sat, 26 Sep 2009 23:41:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A618E3A682D for ; Sat, 26 Sep 2009 23:41:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrnQY-000IJv-Cp for radiusext-data0@psg.com; Sun, 27 Sep 2009 06:40:10 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrnQO-000IJ5-UZ for radiusext@ops.ietf.org; Sun, 27 Sep 2009 06:40:08 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 58F0C123449B; Sun, 27 Sep 2009 08:39:51 +0200 (CEST)
Message-ID: <4ABF08BE.8000904@deployingradius.com>
Date: Sun, 27 Sep 2009 08:39:58 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net> <000401ca3e91$6b916070$42b42150$@net> <4ABDF224.9070307@deployingradius.com> <000b01ca3eaa$9af96b00$d0ec4100$@net> <4ABE24BE.20604@deployingradius.com> <004801ca3f34$03f249e0$0bd6dda0$@net>
In-Reply-To: <004801ca3f34$03f249e0$0bd6dda0$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Actually, _you_ made the claim, I just quoted it.

  Nonsense.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 23:41:49 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF133A6405 for ; Sat, 26 Sep 2009 23:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.056
X-Spam-Level: 
X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdWyic4wLp-f for ; Sat, 26 Sep 2009 23:41:48 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D5C43A682D for ; Sat, 26 Sep 2009 23:41:48 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrnRm-000IQg-Vd for radiusext-data0@psg.com; Sun, 27 Sep 2009 06:41:26 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrnRd-000IQ1-96 for radiusext@ops.ietf.org; Sun, 27 Sep 2009 06:41:24 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 84294123449B; Sun, 27 Sep 2009 08:41:08 +0200 (CEST)
Message-ID: <4ABF090C.2070401@deployingradius.com>
Date: Sun, 27 Sep 2009 08:41:16 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> <4ABDBFE5.4050406@deployingradius.com> <000301ca3e8f$46331a00$d2994e00$@net> <4ABDEF91.5080701@deployingradius.com> <001f01ca3f22$96537410$c2fa5c30$@net>
In-Reply-To: <001f01ca3f22$96537410$c2fa5c30$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
>> After all, it's only a draft.  
> 
> Hmm.  That didn't seem to be relevant when you used it a club (its real
> purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

  Are my comments really that influential?

  I've come along in the world.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sat Sep 26 23:42:28 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93973A6958 for ; Sat, 26 Sep 2009 23:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.369
X-Spam-Level: *
X-Spam-Status: No, score=1.369 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bba9SnTLw6yq for ; Sat, 26 Sep 2009 23:42:27 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B5F13A682D for ; Sat, 26 Sep 2009 23:42:27 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrnRp-000IRA-8n for radiusext-data0@psg.com; Sun, 27 Sep 2009 06:41:29 +0000
Received: from [65.55.116.21] (helo=blu0-omc1-s10.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrnRf-000IQ9-9E for radiusext@ops.ietf.org; Sun, 27 Sep 2009 06:41:27 +0000
Received: from BLU137-W16 ([65.55.116.8]) by blu0-omc1-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Sep 2009 23:41:18 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_71737ae9-ff56-43fb-9fb2-be9bcc78673d_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Re:  IPv6 Address Option
Date: Sat, 26 Sep 2009 23:41:19 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Sep 2009 06:41:18.0743 (UTC) FILETIME=[84D29A70:01CA3F3D]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>"New attributes SHOULD NOT use this tagging method...".  Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that =
described in RFC 2868.  So does the Design Guidelines advice even apply her=
e?  Perhaps the Design Guidelilnes document should be more clear about exac=
tly what the flaws were in the RFC 2868 scheme that the SHOULD NOT applies =
to. =20







 		 	   		  =

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B"New attributes SHOULD NOT use this tagging method...".  Which is it?=


The tagging scheme in draft-lourdelet does not have the same flaws =
as that described in RFC 2868. =3B So does the Design Guidelines advice=
 even apply here? =3B Perhaps the Design Guidelilnes document should be=
 more clear about exactly what the flaws were in the RFC 2868 scheme that t=
he SHOULD NOT applies to. =3B 







 		 	  =
 		  
=

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 00:16:22 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772133A682D for ; Sun, 27 Sep 2009 00:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Level: 
X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzHbG9ukI-ri for ; Sun, 27 Sep 2009 00:16:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6AA423A6849 for ; Sun, 27 Sep 2009 00:16:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrnxs-000LUq-K8 for radiusext-data0@psg.com; Sun, 27 Sep 2009 07:14:36 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrnxi-000LRv-NN for radiusext@ops.ietf.org; Sun, 27 Sep 2009 07:14:34 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D92F6123449B; Sun, 27 Sep 2009 09:14:18 +0200 (CEST)
Message-ID: <4ABF10D1.4050807@deployingradius.com>
Date: Sun, 27 Sep 2009 09:14:25 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: IPv6 Address Option
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
>>"New attributes SHOULD NOT use this tagging method...". Which is it?
> 
> The tagging scheme in draft-lourdelet does not have the same flaws as
> that described in RFC 2868.  So does the Design Guidelines advice even
> apply here?

  The draft-lourdelet document defines a new data type.  8-bit tag,
followed by 32-bit integer.  While this is arguably better than the RFC
2868 form, it still is a new data type.  And the document discourages
new data types.

  As with most protocol design, there is room for an intelligent
application of checks and balances.  The issues associated with defining
a new data type should be weighed against the issues associated with
re-using a deprecated data type.

  An application of intelligence is suggested.  A thoughtless
application of the guidelines is not appropriate, as is a thoughtless
rejection of it.  I will note that the *only* "MUST" text in the
document is:

   1) provisioning of new services MUST be done in the IETF

   2) service provisioning MUST NOT be done in Access-Reject.

  All other "MUST" text in the documents are quotes from other RFCs.

  Hence, the suggestions of the guidelines documents are SHOULD, SHOULD
NOT, etc.  A reviewer following the guidelines document is perfectly
free to *not* follow its suggestions, if he believes that doing so would
be worse than the alternatives.

  Maybe the document needs to say:

   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  As a result,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.  Reviewers are expected to weigh the cost and
   benefits of following or ignoring the guidelines, as nearly all
   suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
   intent is for the guidelines to help authors create better documents.
   This intent means that reviewers can choose to ignore some of the
   recommendations herein.  When this is done, their review MUST be
   accompanied by an explanation as to why the guidelines were not
   followed, and why following the guidelines would have resulted in
   a worse architecture.

>  Perhaps the Design Guidelilnes document should be more
> clear about exactly what the flaws were in the RFC 2868 scheme that the
> SHOULD NOT applies to. 

  Or, it could say that the tagging mechanism MAY be used when none of
the above limitations apply.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 00:38:48 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477D13A67F1 for ; Sun, 27 Sep 2009 00:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.839
X-Spam-Level: *
X-Spam-Status: No, score=1.839 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwsav4ovGQW4 for ; Sun, 27 Sep 2009 00:38:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D1833A67C2 for ; Sun, 27 Sep 2009 00:38:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MroJr-000Nq3-Bi for radiusext-data0@psg.com; Sun, 27 Sep 2009 07:37:19 +0000
Received: from [76.96.62.48] (helo=QMTA05.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MroJh-000NpQ-I2 for radiusext@ops.ietf.org; Sun, 27 Sep 2009 07:37:17 +0000
Received: from OMTA19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ljd91c00327AodY55jd9yA; Sun, 27 Sep 2009 07:37:09 +0000
Received: from gwzPC ([124.121.210.34]) by OMTA19.westchester.pa.mail.comcast.net with comcast id lji21c0010l4j3Q3fji92a; Sun, 27 Sep 2009 07:42:25 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
Cc: 
References: 
In-Reply-To: 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 14:36:16 +0700
Message-ID: <006401ca3f45$408ff530$c1afdf90$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01CA3F7F.ECEECD30"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco/PdailSukUmU2QziPXjtoXbjpGQABrBXg
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01CA3F7F.ECEECD30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba  
[mailto://bernard_aboba@hotmail.com] writes:

 

>"New attributes SHOULD NOT use this tagging method...". Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that
described in RFC 2868.  So does the Design Guidelines advice even apply
here?  Perhaps the Design Guidelilnes document should be more clear about
exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT
applies to.  



Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.








	

 


------=_NextPart_000_0065_01CA3F7F.ECEECD30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Bernard Aboba [mailto://bernard_aboba@hotmail.com] =
writes:



 






>"New attributes SHOULD NOT =
use
this tagging method...". Which is it?



The tagging scheme in draft-lourdelet does not have the same flaws as =
that
described in RFC 2868.  So does the Design Guidelines advice even =
apply
here?  Perhaps the Design Guidelilnes document should be more clear =
about
exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT =
applies
to.  







Somebody should =
note (might
as well be me) that since the 1) the document is not a protocol =
specification
& 2) the intended status is BCP, the use of RFC 2118 keywords is =
inappropriate
to begin with.


















 

  
 





 












------=_NextPart_000_0065_01CA3F7F.ECEECD30--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 00:48:42 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D3B3A688A for ; Sun, 27 Sep 2009 00:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.657
X-Spam-Level: *
X-Spam-Status: No, score=1.657 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJoMI8Q-vteG for ; Sun, 27 Sep 2009 00:48:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78C273A6926 for ; Sun, 27 Sep 2009 00:48:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MroT0-000Ojr-LX for radiusext-data0@psg.com; Sun, 27 Sep 2009 07:46:46 +0000
Received: from [65.55.111.97] (helo=blu0-omc2-s22.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MroSr-000OjB-6I for radiusext@ops.ietf.org; Sun, 27 Sep 2009 07:46:44 +0000
Received: from BLU137-W14 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 00:46:36 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_84ad55d2-3394-4fe9-b938-55e63f669c2a_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 00:46:36 -0700
Importance: Normal
In-Reply-To: <4ABF10D1.4050807@deployingradius.com>
References: 
X-OriginalArrivalTime: 27 Sep 2009 07:46:36.0482 (UTC) FILETIME=[A3FA2220:01CA3F46]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

 <4ABF10D1.4050807@deployingradius.com>
MIME-Version: 1.0

--_84ad55d2-3394-4fe9-b938-55e63f669c2a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   The draft-lourdelet document defines a new data type.  8-bit tag=2C
> followed by 32-bit integer.  While this is arguably better than the RFC
> 2868 form=2C it still is a new data type.  And the document discourages
> new data types.

OK.  So the issue is not the use of RFC 2868 tags.=20

>   Maybe the document needs to say:
>=20
>    In order to meet these objectives=2C this document needs to cover not
>    only the science of attribute design=2C but also the art.  As a result=
=2C
>    in addition to covering the most frequently encountered issues=2C this
>    document attempts to provide some of the considerations motivating
>    the guidelines.  Reviewers are expected to weigh the cost and
>    benefits of following or ignoring the guidelines=2C as nearly all
>    suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
>    intent is for the guidelines to help authors create better documents.
>    This intent means that reviewers can choose to ignore some of the
>    recommendations herein.  When this is done=2C their review MUST be
>    accompanied by an explanation as to why the guidelines were not
>    followed=2C and why following the guidelines would have resulted in
>    a worse architecture.

Personally=2C I don't think this text is necessary=3B RFC 2119 defines the
meaning of SHOULD.=20

> >  Perhaps the Design Guidelilnes document should be more
> > clear about exactly what the flaws were in the RFC 2868 scheme that the
> > SHOULD NOT applies to.=20
>=20
>   Or=2C it could say that the tagging mechanism MAY be used when none of
> the above limitations apply.

Or=2C it might describe how a single octet tagging scheme might avoid the
problems of RFC 2868.=20
 		 	   		  =

--_84ad55d2-3394-4fe9-b938-55e63f669c2a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B   The draft-lourdelet document defines a new data type.  8-bit tag=
=2C
>=3B followed by 32-bit integer.  While this is arguably better th=
an the RFC
>=3B 2868 form=2C it still is a new data type.  And the doc=
ument discourages
>=3B new data types.

OK. =3B So the issue=
 is not the use of RFC 2868 tags. 

>=3B   Maybe the document needs=
 to say:
>=3B 
>=3B    In order to meet these objectives=2C this =
document needs to cover not
>=3B    only the science of attribute desi=
gn=2C but also the art.  As a result=2C
>=3B    in addition to coverin=
g the most frequently encountered issues=2C this
>=3B    document atte=
mpts to provide some of the considerations motivating
>=3B    the guid=
elines.  Reviewers are expected to weigh the cost and
>=3B    benefits=
 of following or ignoring the guidelines=2C as nearly all
>=3B    sugg=
estions here are of the form "SHOULD" or "SHOULD NOT".  The
>=3B    in=
tent is for the guidelines to help authors create better documents.
>=
=3B    This intent means that reviewers can choose to ignore some of the>=3B    recommendations herein.  When this is done=2C their review MUST =
be
>=3B    accompanied by an explanation as to why the guidelines were=
 not
>=3B    followed=2C and why following the guidelines would have r=
esulted in
>=3B    a worse architecture.

Personally=2C I don't =
think this text is necessary=3B RFC 2119 defines the
meaning of SHOULD. =


>=3B >=3B  Perhaps the Design Guidelilnes document should be mo=
re
>=3B >=3B clear about exactly what the flaws were in the RFC 2868=
 scheme that the
>=3B >=3B SHOULD NOT applies to. 
>=3B 
>=
=3B   Or=2C it could say that the tagging mechanism MAY be used when none o=
f
>=3B the above limitations apply.

Or=2C it might describe how=
 a single octet tagging scheme might avoid the
problems of RFC 2868.  		 	   		  
=

--_84ad55d2-3394-4fe9-b938-55e63f669c2a_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 00:50:00 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D213A687C for ; Sun, 27 Sep 2009 00:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.667
X-Spam-Level: *
X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS8msbrkrJuL for ; Sun, 27 Sep 2009 00:49:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 582CD3A67B0 for ; Sun, 27 Sep 2009 00:49:59 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MroUz-000OwK-HC for radiusext-data0@psg.com; Sun, 27 Sep 2009 07:48:49 +0000
Received: from [65.55.111.154] (helo=blu0-omc4-s15.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MroUo-000Ove-TJ for radiusext@ops.ietf.org; Sun, 27 Sep 2009 07:48:46 +0000
Received: from BLU137-W36 ([65.55.111.135]) by blu0-omc4-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 00:48:38 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_2a5ac828-0a61-4a61-abdb-6d211e67d088_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Glen Zorn 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 00:48:38 -0700
Importance: Normal
In-Reply-To: <006401ca3f45$408ff530$c1afdf90$@net>
References: 
X-OriginalArrivalTime: 27 Sep 2009 07:48:38.0557 (UTC) FILETIME=[ECBD4CD0:01CA3F46]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

 <006401ca3f45$408ff530$c1afdf90$@net>
MIME-Version: 1.0

--_2a5ac828-0a61-4a61-abdb-6d211e67d088_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Somebody should note (might
as well be me) that since the 1) the document is not a protocol specificati=
on
& 2) the intended status is BCP=2C the use of RFC 2118 keywords is inapprop=
riate
to begin with.



[BA] Where does it say that BCPs can't contain normative keywords?  Lots of=
 other BCPs seem to use them.=20










=20
 =20

=20


=20



 		 	   		  =

--_2a5ac828-0a61-4a61-abdb-6d211e67d088_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












Somebody should note (might
as well be me) that since the 1) the document is not a protocol specificati=
on
&=3B 2) the intended status is BCP=2C the use of RFC 2118 keywords is in=
appropriate
to begin with.





[BA] Where does it say that BCPs can't contain normative keywords? =3B =
Lots of other BCPs seem to use them. 












 

  

 





 =3B






 		 	   		  
=

--_2a5ac828-0a61-4a61-abdb-6d211e67d088_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 01:02:42 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDD128C0E1 for ; Sun, 27 Sep 2009 01:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.397
X-Spam-Level: *
X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOx5owNQVKwA for ; Sun, 27 Sep 2009 01:02:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B20C3A68A1 for ; Sun, 27 Sep 2009 01:02:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrohi-0000DE-4n for radiusext-data0@psg.com; Sun, 27 Sep 2009 08:01:58 +0000
Received: from [65.55.116.46] (helo=blu0-omc1-s35.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrohV-0000CH-No for radiusext@ops.ietf.org; Sun, 27 Sep 2009 08:01:55 +0000
Received: from BLU137-W31 ([65.55.116.7]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 01:01:45 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Re:  IPv6
Date: Sun, 27 Sep 2009 01:01:45 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Sep 2009 08:01:45.0312 (UTC) FILETIME=[C1AE9600:01CA3F48]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Alan DeKok said:

"I suggest racing against the design guidelines document.  After all=2C
it's only a draft.  If the IPv6 document can get published first=2C then
the design guidelines matter a lot less."

[BA] Either the Design Guidelines advice is appropriate or it isn't.=20

If it isn't right=2C then we should fix it=2C because eventually it will be=
come an RFC and "racing against" it won't work any more.=20
If it is right=2C then we should try to adhere to the guidelines -- that's =
what they are there for.=20

In this particular case=2C my take is that the Design Guidelines document i=
s saying "don't do precisely what RFC 2868 did".  That is quite sensible.  =
However=2C it might also be helpful to say "Here are the problems that were=
 caused by RFC 2868's scheme=2C and here is some advice to avoid those issu=
es".  That way=2C until we finish the Extended Attributes document=2C we'll=
 have some way to address these kind of situations.=20





 		 	   		  =

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Alan DeKok said:

"I suggest racing against the design guidelines doc=
ument.  After all=2C
it's only a draft.  If the IPv6 document can get pu=
blished first=2C then
the design guidelines matter a lot less."

[=
BA] Either the Design Guidelines advice is appropriate or it isn't. 
If it isn't right=2C then we should fix it=2C because eventually it will b=
ecome an RFC and "racing against" it won't work any more. 
If it is righ=
t=2C then we should try to adhere to the guidelines -- that's what they are=
 there for. 

In this particular case=2C my take is that the Design G=
uidelines document is saying "don't do precisely what RFC 2868 did". =
=3B That is quite sensible. =3B However=2C it might also be helpful to =
say "Here are the problems that were caused by RFC 2868's scheme=2C and her=
e is some advice to avoid those issues". =3B That way=2C until we finis=
h the Extended Attributes document=2C we'll have some way to address these =
kind of situations. 





 		 	   		  
=

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 02:00:09 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4DB3A6926 for ; Sun, 27 Sep 2009 02:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.854
X-Spam-Level: *
X-Spam-Status: No, score=1.854 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naYxemUTw+Vq for ; Sun, 27 Sep 2009 02:00:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C99593A692A for ; Sun, 27 Sep 2009 02:00:08 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrpaj-0005ce-MB for radiusext-data0@psg.com; Sun, 27 Sep 2009 08:58:49 +0000
Received: from [76.96.59.212] (helo=QMTA14.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrpaZ-0005c7-EK for radiusext@ops.ietf.org; Sun, 27 Sep 2009 08:58:47 +0000
Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA14.westchester.pa.mail.comcast.net with comcast id lkwC1c0021YDfWL5EkyfW6; Sun, 27 Sep 2009 08:58:39 +0000
Received: from gwzPC ([124.121.210.34]) by OMTA20.westchester.pa.mail.comcast.net with comcast id ll2M1c0040l4j3Q3gl2UKV; Sun, 27 Sep 2009 09:02:45 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
Cc: 
References:  
In-Reply-To: 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 15:57:45 +0700
Message-ID: <008901ca3f50$a322c960$e9685c20$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01CA3F8B.4F81A160"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco/Ru2ZQkifLn25Qk2hPLb844lVIQACSyng
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01CA3F8B.4F81A160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.


[BA] Where does it say that BCPs can't contain normative keywords?  Lots of
other BCPs seem to use them. 

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

 

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

 


------=_NextPart_000_008A_01CA3F8B.4F81A160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

























Bernard Aboba
[mailto:bernard_aboba@hotmail.com] writes:

Somebody should note (might as well be me) that since the =
1) the
document is not a protocol specification & 2) the intended status is =
BCP,
the use of RFC 2118 keywords is inappropriate to begin with.=






[BA] Where does it say that BCPs can't contain normative keywords?  =
Lots
of other BCPs seem to use them. 



WRT this document, section 6 of RFC 2119 (sorry about the =
typo
above) seems relevant:



6. Guidance in the use of these =
Imperatives



 



   Imperatives of the type defined =
in this
memo must be used with care



   and sparingly.  In =
particular,
they MUST only be used where it is



   actually required for =
interoperation or
to limit behavior which has



   potential for causing harm =
(e.g.,
limiting retransmisssions)  For



   example, they must not be used =
to try
to impose a particular method



   on implementors where the method =
is not
required for



   =
interoperability.



 


















------=_NextPart_000_008A_01CA3F8B.4F81A160--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 02:18:43 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A38E3A693D for ; Sun, 27 Sep 2009 02:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.092
X-Spam-Level: 
X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-1.456, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzs4vzyoD8NV for ; Sun, 27 Sep 2009 02:18:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DECE3A67CC for ; Sun, 27 Sep 2009 02:18:42 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrpst-0007JI-Ta for radiusext-data0@psg.com; Sun, 27 Sep 2009 09:17:35 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrpsk-0007Gn-Dx for radiusext@ops.ietf.org; Sun, 27 Sep 2009 09:17:33 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id B08E9123449B; Sun, 27 Sep 2009 11:17:21 +0200 (CEST)
Message-ID: <4ABF2DA4.7080602@deployingradius.com>
Date: Sun, 27 Sep 2009 11:17:24 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: IPv6
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba wrote:
> Alan DeKok said:
> 
> "I suggest racing against the design guidelines document. After all,
> it's only a draft. If the IPv6 document can get published first, then
> the design guidelines matter a lot less."
> 
> [BA] Either the Design Guidelines advice is appropriate or it isn't.

  The comment was an attempt at humor, to counter the vitriol directed
at the design guidelines document.

> In this particular case, my take is that the Design Guidelines document
> is saying "don't do precisely what RFC 2868 did".  That is quite
> sensible.  However, it might also be helpful to say "Here are the
> problems that were caused by RFC 2868's scheme, and here is some advice
> to avoid those issues".  That way, until we finish the Extended
> Attributes document, we'll have some way to address these kind of
> situations.

  Update 2.1.1 Tag Mechanism:

Old text:

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.

New text:

   Where these limitations do not apply, new attributes MAY use this
   tagging method, though it is NOT RECOMMENDED.  Where the above
   limitations apply, this tagging method SHOULD NOT be used.


  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 05:59:52 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844833A6884 for ; Sun, 27 Sep 2009 05:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.986
X-Spam-Level: 
X-Spam-Status: No, score=0.986 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3famBwRzbPfA for ; Sun, 27 Sep 2009 05:59:51 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B18B03A67B4 for ; Sun, 27 Sep 2009 05:59:51 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrtJc-0001QD-Rc for radiusext-data0@psg.com; Sun, 27 Sep 2009 12:57:24 +0000
Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrtJS-0001PV-Ri for radiusext@ops.ietf.org; Sun, 27 Sep 2009 12:57:22 +0000
Received: from OMTA18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id lou61c0061bwxycA3oxFRW; Sun, 27 Sep 2009 12:57:15 +0000
Received: from NEWTON603 ([71.232.143.198]) by OMTA18.emeryville.ca.mail.comcast.net with comcast id lp2g1c0074H2mdz8ep2hie; Sun, 27 Sep 2009 13:02:42 +0000
From: "Dave Nelson" 
To: 
References: 
Subject: RE: IPv6
Date: Sun, 27 Sep 2009 08:57:24 -0400
Message-ID: <5E49445CEA8F4CE39B1F29FB9084D344@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 
Thread-Index: Aco/SQYKSHf8WplWSkuL3QuQe5OoFwAKNIUg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Bernard Aboba writes...

> Either the Design Guidelines advice is appropriate or it isn't. 
>
> If it isn't right, then we should fix it, because eventually
> it will become an RFC and "racing against" it won't work any
> more.  If it is right, then we should try to adhere to the
> guidelines -- that's what they are there for.

+1



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 08:48:27 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA66728C0E0 for ; Sun, 27 Sep 2009 08:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.684
X-Spam-Level: *
X-Spam-Status: No, score=1.684 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av8sOmIMKM4s for ; Sun, 27 Sep 2009 08:48:26 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 836DF3A69D9 for ; Sun, 27 Sep 2009 08:48:26 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrvxZ-000FMZ-3Y for radiusext-data0@psg.com; Sun, 27 Sep 2009 15:46:49 +0000
Received: from [65.55.111.109] (helo=blu0-omc2-s34.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrvxP-000FM2-7P for radiusext@ops.ietf.org; Sun, 27 Sep 2009 15:46:46 +0000
Received: from BLU137-W4 ([65.55.111.71]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 08:46:39 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_289e488d-de66-4fff-bd63-021df62db0b7_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6
Date: Sun, 27 Sep 2009 08:46:39 -0700
Importance: Normal
In-Reply-To: <4ABF2DA4.7080602@deployingradius.com>
References: 
X-OriginalArrivalTime: 27 Sep 2009 15:46:39.0201 (UTC) FILETIME=[B3BC4510:01CA3F89]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

 <4ABF2DA4.7080602@deployingradius.com>
MIME-Version: 1.0

--_289e488d-de66-4fff-bd63-021df62db0b7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Old text:
>=20
>    New attributes SHOULD NOT use this tagging method because of the
>    limitations described above.
>=20
> New text:
>=20
>    Where these limitations do not apply=2C new attributes MAY use this
>    tagging method=2C though it is NOT RECOMMENDED.  Where the above
>    limitations apply=2C this tagging method SHOULD NOT be used.

Here is the original text of Section 2.1.2:

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values=2C because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (assuming the tag is optional).

   Other limitations of the tagging mechanism are that when integer
   values are tagged=2C the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.
"

How about this?=20

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.
   As stated in [RFC2868] Section 3.3:

      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F=2C it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F=2C it SHOULD be
      interpreted as the first byte of the following String field.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values=2C because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (e.g. where the first byte of the following
   String field falls in the range of 0x00 through 0x1F).=20

   Other limitations of the tagging mechanism are that when integer
   values are tagged=2C the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

   For these reasons=2C the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types=2C
   it is RECOMMENDED that:
     =20
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present=3B=20

        * The design make no assumption about the content of the
          data within tagged attributes." =20




 		 	   		  =

--_289e488d-de66-4fff-bd63-021df62db0b7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B Old text:
>=3B 
>=3B    New attributes SHOULD NOT use this=
 tagging method because of the
>=3B    limitations described above.>=3B 
>=3B New text:
>=3B 
>=3B    Where these limitation=
s do not apply=2C new attributes MAY use this
>=3B    tagging method=
=2C though it is NOT RECOMMENDED.  Where the above
>=3B    limitations=
 apply=2C this tagging method SHOULD NOT be used.

Here is the origin=
al text of Section 2.1.2:

"
2.1.2.  Tagging Mechanism

   =
[RFC2868] defines an attribute grouping mechanism based on the use of
  =
 a one octet tag value.  Tunnel attributes that refer to the same
   tun=
nel are grouped together by virtue of using the same tag value.

   T=
his tagging mechanism has some drawbacks.  There are a limited
   number=
 of unique tags (31).  The tags are not well suited for use
   with arbi=
trary binary data values=2C because it is not always possible
   to tell=
 if the first byte after the Length is the tag or the first
   byte of t=
he untagged value (assuming the tag is optional).

   Other limitatio=
ns of the tagging mechanism are that when integer
   values are tagged=
=2C the value portion is reduced to three bytes
   meaning only 24-bit n=
umbers can be represented.  The tagging
   mechanism does not offer an a=
bility to create nested groups of
   attributes.  Some RADIUS implementa=
tions treat tagged attributes as
   having additional data types tagged-=
string and tagged-integer.  These
   types increase the complexity of im=
plementing and managing RADIUS
   systems.

   New attributes SHOU=
LD NOT use this tagging method because of the
   limitations described a=
bove.
"

How about this? 

"2.1.2.  Tagging Mecha=
nism

   [RFC2868] defines an attribute grouping mechanism based on t=
he use of
   a one octet tag value.  Tunnel attributes that refer to the=
 same
   tunnel are grouped together by virtue of using the same tag val=
ue.
   As stated in [RFC2868] Section 3.3:

      The Tag field is=
 one octet in length and is intended to provide a
      means of groupin=
g attributes in the same packet which refer to the
      same tunnel.  I=
f the value of the Tag field is greater than 0x00
      and less than or=
 equal to 0x1F=2C it SHOULD be interpreted as
      indicating which tun=
nel (of several alternatives) this attribute
      pertains.  If the Tag=
 field is greater than 0x1F=2C it SHOULD be
      interpreted as the fir=
st byte of the following String field.

   This tagging mechanism has=
 some drawbacks.  There are a limited
   number of unique tags (31).  Th=
e tags are not well suited for use
   with arbitrary binary data values=
=2C because it is not always possible
   to tell if the first byte after=
 the Length is the tag or the first
   byte of the untagged value (e.g. =
where the first byte of the following
   String field falls in the range=
 of 0x00 through 0x1F). 

   Other limitations of the tagging mechani=
sm are that when integer
   values are tagged=2C the value portion is re=
duced to three bytes
   meaning only 24-bit numbers can be represented. =
 The tagging
   mechanism does not offer an ability to create nested gro=
ups of
   attributes.  Some RADIUS implementations treat tagged attribut=
es as
   having additional data types tagged-string and tagged-integer. =
 These
   types increase the complexity of implementing and managing RAD=
IUS
   systems.

   For these reasons=2C the tagging scheme descri=
bed in RFC 2868 is
   not suitable for use as a generic grouping mechani=
sm.  Where
   a tagging scheme is required for use with arbitrary data t=
ypes=2C
   it is RECOMMENDED that:
      
        * A fixed taggin=
g field be used so as to remove potential
          interoperability iss=
ues associated with determining whether
          an optional tag is pre=
sent=3B 

        * The design make no assumption about the content o=
f the
          data within tagged attributes."  




 		 	   		  
=

--_289e488d-de66-4fff-bd63-021df62db0b7_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 09:00:13 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4C23A69C6 for ; Sun, 27 Sep 2009 09:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.693
X-Spam-Level: *
X-Spam-Status: No, score=1.693 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKoTUnXO1AQ0 for ; Sun, 27 Sep 2009 09:00:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03DCB3A68E7 for ; Sun, 27 Sep 2009 09:00:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrw8Y-000Gpw-By for radiusext-data0@psg.com; Sun, 27 Sep 2009 15:58:10 +0000
Received: from [65.55.111.150] (helo=blu0-omc4-s11.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mrw8P-000GpK-2A for radiusext@ops.ietf.org; Sun, 27 Sep 2009 15:58:08 +0000
Received: from BLU137-W10 ([65.55.111.136]) by blu0-omc4-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 08:58:01 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_80404be2-30c3-4199-a317-19e38825fbf0_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Glen Zorn 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 08:58:00 -0700
Importance: Normal
In-Reply-To: <008901ca3f50$a322c960$e9685c20$@net>
References:  
X-OriginalArrivalTime: 27 Sep 2009 15:58:01.0015 (UTC) FILETIME=[4A20D470:01CA3F8B]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

 <008901ca3f50$a322c960$e9685c20$@net>
MIME-Version: 1.0

--_80404be2-30c3-4199-a317-19e38825fbf0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




WRT this document=2C section 6 of RFC 2119 (sorry about the typo
above) seems relevant:

6. Guidance in the use of these Imperatives

=20

   Imperatives of the type defined in this
memo must be used with care

   and sparingly.  In particular=2C
they MUST only be used where it is

   actually required for interoperation or
to limit behavior which has

   potential for causing harm (e.g.=2C
limiting retransmisssions)  For

   example=2C they must not be used to try
to impose a particular method

   on implementors where the method is not
required for

   interoperability.

=20
[BA] Are there specific uses of normative language in the document that you=
 believe are inappropriate? =20







 		 	   		  =

--_80404be2-30c3-4199-a317-19e38825fbf0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








WRT this document=2C section 6 o=
f RFC 2119 (sorry about the typo
above) seems relevant:



6. Guidance in the use of these Imperatives



 =3B



 =3B =3B Imperatives of the type defined=
 in this
memo must be used with care



 =3B =3B and sparingly. =3B In parti=
cular=2C
they MUST only be used where it is



 =3B =3B actually required for interoper=
ation or
to limit behavior which has



 =3B =3B potential for causing harm (e.g=
.=2C
limiting retransmisssions) =3B For



 =3B =3B example=2C they must not be use=
d to try
to impose a particular method



 =3B =3B on implementors where the metho=
d is not
required for



 =3B =3B interoperability.



 =3B=


=

[BA] Are there specific uses of normative language in the document that=
 you believe are inappropriate?  =3B











 		 	   		  
=

--_80404be2-30c3-4199-a317-19e38825fbf0_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 09:12:55 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2D93A6969 for ; Sun, 27 Sep 2009 09:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iddSqPg0067g for ; Sun, 27 Sep 2009 09:12:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3635A3A6852 for ; Sun, 27 Sep 2009 09:12:54 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrwLm-000Hxs-Lm for radiusext-data0@psg.com; Sun, 27 Sep 2009 16:11:50 +0000
Received: from [65.55.116.33] (helo=blu0-omc1-s22.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrwLc-000Hwq-Vz for radiusext@ops.ietf.org; Sun, 27 Sep 2009 16:11:48 +0000
Received: from BLU137-W24 ([65.55.116.8]) by blu0-omc1-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 09:11:40 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_ab60308e-9082-46a5-8e1b-ccdf8704a708_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Agenda for Interim Meeting - Take Two
Date: Sun, 27 Sep 2009 09:11:40 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Sep 2009 16:11:40.0327 (UTC) FILETIME=[3279EB70:01CA3F8D]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Strawman Agenda

8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Agenda Bash
   Document Status=20

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

Under Consideration for Adoption (30 minutes)

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

9:30 AM - 9:40 AM Requirements for IPv6 over PPP=2C David Miles (10 minutes=
)
http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access

9:40 AM - 9:50 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba =
(10 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan



 		 	   		  =

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Strawman Agenda

8:00 AM - 8:20 AM  Preliminaries
   Jabber s=
cribe
   Agenda Bash
   Document Status 

Documents completing =
IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines docu=
ment=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-r=
adext-design

Documents Completing WG Last Call (20 minutes)

8=
:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.=
org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server do=
cument=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-=
radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C A=
lan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-=
transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-ba=
sed Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/h=
tml/draft-ietf-radext-dynamic-discovery

Under Consideration for Adop=
tion (30 minutes)

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (=
10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

9:=
30 AM - 9:40 AM Requirements for IPv6 over PPP=2C David Miles (10 minutes)<=
br>http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access

9:4=
0 AM - 9:50 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba (10=
 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan


=


 		 	   		  
=

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 09:44:46 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859F83A68B7 for ; Sun, 27 Sep 2009 09:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.225
X-Spam-Level: 
X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=-1.374, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48cUIpgXjRlV for ; Sun, 27 Sep 2009 09:44:45 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 393543A6837 for ; Sun, 27 Sep 2009 09:44:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrwqP-000KDr-FA for radiusext-data0@psg.com; Sun, 27 Sep 2009 16:43:29 +0000
Received: from web111408.mail.gq1.yahoo.com ([67.195.15.174]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MrwqA-000KC1-Sk for radiusext@ops.ietf.org; Sun, 27 Sep 2009 16:43:27 +0000
Received: (qmail 35953 invoked by uid 60001); 27 Sep 2009 16:43:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254069793; bh=bCG7Ft38AZ5Jo3LI7npd0E8Nx66jLybPRZ9S28+BQk0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LrPVkX/Kk3bXrGGF2G0kVh9g2X9GjT5siLXuWP0G+J+/shXK2ZbhIeYcS4HW2yBWlHDFRQIqjxCzE5CrKbhCjeNSGypnt4SKq7g0/IuwgESWQ1Ijq/ooxz2QwhxUCo3J3qvulCcjYACCFktv8wCKIjZ7kkhYAsmbOVqbWe6wzDQ=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DswOxkZU6co4RIAU/kB0m4+l5htllaTKYKOW4ADeD8WMWbg9JBG590clcquZdL6P2Yc8nm6zwO0aJSBybPZ/e2mUf+OHcvBgl4oE3amB3KP8l3MYOfGj6p/oxrwBMa+QPK1o/tpfQITBz4skQIRt2+aONwujPrcJPo58zoIjues=;
Message-ID: <481809.34957.qm@web111408.mail.gq1.yahoo.com>
X-YMail-OSG: JltXC14VM1krmWtajVdEwJVGUwKjz2T9KqiDkTUVmvs9UQqc7e0OcfxE6HDBxKCe98Gk_oeGAifaOJxzZW8kpd9iscEm4vzGMfc7.J2jaXgEjb1oY9OTtDdkP3fZaaxevBK54.XO53dyZe5vjXNQrgebik0KrdQNYZuV0rBlm7KQwR1LkohNpVyYs5NJ4Veo7HgSUakFsv8xBrgpPTi4zRspBwbpd5grOqEQoWZOhQ0kHrPgnTS9_zUL9nybtwUkMOsWhU6Tt8RBYfZBa9wt.NuWz5H_DBp.o7Kc7FhGf4ZKlhCO9TzJ
Received: from [72.64.108.212] by web111408.mail.gq1.yahoo.com via HTTP; Sun, 27 Sep 2009 09:43:13 PDT
X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> 
Date: Sun, 27 Sep 2009 09:43:13 -0700 (PDT)
From: Behcet Sarikaya 
Reply-To: Behcet Sarikaya 
Subject: Re: IPv6 Address Option
To: Bernard Aboba , david.miles@alcatel-lucent.com.au, "radiusext@ops.ietf.org" , "David B. Nelson" 
Cc: roberta.maglione@telecomitalia.it, Mark Townsley 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Hi Bernard,


>
>From: Bernard Aboba 
>To: david.miles@alcatel-lucent.com.au; "radiusext@ops.ietf.org" ; David B. Nelson 
>Cc: roberta.maglione@telecomitalia.it; Mark Townsley 
>Sent: Saturday, September 26, 2009 7:21:27 PM
>Subject: RE: IPv6 Address Option
>
> >
>> A few months back some of us expressed a desire to proceed with the
>> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
>> item. 
>
>On June 25, 2009 there was a WG call for interest in the document: 
>http://ops.ietf.org/lists/radiusext/2009/msg00273.html
>
>Only one person other than yourself and the authors replied to the call for interest. 
>

No. Several people replie. They just supported the call without any comments, but they promised to comment.

>In addition, the document has not been revised in response to WG comments. 
>
>> In the recent Broadband Forum meeting in Tokyo it was announced
>> that the BBF will seek to finalize their document on IPv6 for PPP
>> environments (to which I am co-editor). With the lack of some essential
>> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
>> a hard place.
>
>If there was interest from the Broadband Forum, why has noone bothered to
>respond to the call for interest or to revise the document? 
>
>> Delaying the IPv6 for PPP document much beyond November is not an option
>
>If that is the case, why are the concerned parties not doing more to move it forward? 
>
>> I am happy to work with the current authors to create a draft which can be fast tracked.
>
>If you're volunteering to act as editor, that would be great.  Next step would be to issue a 
>version of the document addressing outstanding comments.  We can then discuss the 
>document at the October 13 Virtual Interim meeting. 
>
>

Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

Regards,

Behcet



      

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 13:23:07 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6336F3A6911 for ; Sun, 27 Sep 2009 13:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.71
X-Spam-Level: *
X-Spam-Status: No, score=1.71 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al40aXsnmFdB for ; Sun, 27 Sep 2009 13:23:06 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 697F63A68F6 for ; Sun, 27 Sep 2009 13:23:06 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms0CV-000HFJ-Ho for radiusext-data0@psg.com; Sun, 27 Sep 2009 20:18:31 +0000
Received: from [65.55.116.25] (helo=blu0-omc1-s14.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms0CJ-000HDv-3s for radiusext@ops.ietf.org; Sun, 27 Sep 2009 20:18:29 +0000
Received: from BLU137-W14 ([65.55.116.9]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Sep 2009 13:18:16 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_488386de-41e2-4753-a9c4-1561c6b41365_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: , , "radiusext@ops.ietf.org" , "David B. Nelson" 
CC: , Mark Townsley 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 13:18:16 -0700
Importance: Normal
In-Reply-To: <481809.34957.qm@web111408.mail.gq1.yahoo.com>
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com> 
X-OriginalArrivalTime: 27 Sep 2009 20:18:16.0266 (UTC) FILETIME=[A58B0AA0:01CA3FAF]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

 <481809.34957.qm@web111408.mail.gq1.yahoo.com>
MIME-Version: 1.0

--_488386de-41e2-4753-a9c4-1561c6b41365_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> No. Several people replied. They just supported the call without any comm=
ents=2C but they promised to comment.

In looking at the archive=2C these are the only people whose response indic=
ated support of the document:=20

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html

Aside from these individuals=2C who else has indicated support for the docu=
ment?  Please provide links to their emails.=20

>Well=2C we certainly would be happy to have David on board. However=2C I t=
hink the document already has an editor=2C actually two=2C i.e. Benoit and =
Glen.We could have three :).

The issue isn't how many editors the document has.  The issue is the pace a=
t which the document has evolved in response to feedback. =20

The IETF isn't a "work for hire" organization that exists to produce work i=
n response to liaison requests.  If an SDO such as Broadband Forum wants a =
document to move forward=2C then they need to supply the manpower to comple=
te the work=2C and enough people interested in it to provide appropriate re=
view.  Providing deadlines without engaged people doesn't help.=20

And if some aspect of the IETF process is acting as a bottleneck=2C the Des=
ign Guidelines document specifically provides a mechanism for the Broadband=
 Forum to complete the work on its own=2C engaging the IETF for review.=20







 		 	   		  =

--_488386de-41e2-4753-a9c4-1561c6b41365_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







>=3B No. Several people replied. They just supported the call without=
 any comments=2C but they promised to comment.

In looking at the arc=
hive=2C these are the only people whose response indicated support of the d=
ocument: 

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/20=
09/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/m=
sg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00=
354.html

Aside from these individuals=2C who else has indicated supp=
ort for the document? =3B Please provide links to their emails. 
>=3BWell=2C we certainly would be happy to have David on board. However=
=2C I think the document already has an editor=2C actually two=2C i.e. Beno=
it and Glen.We could have three :).

The issue isn't how many editors=
 the document has. =3B The issue is the pace at which the document has =
evolved in response to feedback. =3B 

The IETF isn't a "work for=
 hire" organization that exists to produce work in response to liaison requ=
ests. =3B If an SDO such as Broadband Forum wants a document to move fo=
rward=2C then they need to supply the manpower to complete the work=2C and =
enough people interested in it to provide appropriate review. =3B Provi=
ding deadlines without engaged people doesn't help. 

And if some asp=
ect of the IETF process is acting as a bottleneck=2C the Design Guidelines =
document specifically provides a mechanism for the Broadband Forum to compl=
ete the work on its own=2C engaging the IETF for review. 






 		 	   		  
=

--_488386de-41e2-4753-a9c4-1561c6b41365_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 18:34:35 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A743A683E for ; Sun, 27 Sep 2009 18:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.173
X-Spam-Level: 
X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAXTjX3KMapW for ; Sun, 27 Sep 2009 18:34:32 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58B9C3A696B for ; Sun, 27 Sep 2009 18:34:32 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms53t-000LGI-Mq for radiusext-data0@psg.com; Mon, 28 Sep 2009 01:29:57 +0000
Received: from [76.96.59.243] (helo=QMTA13.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms53i-000LFH-5r for radiusext@ops.ietf.org; Mon, 28 Sep 2009 01:29:55 +0000
Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA13.westchester.pa.mail.comcast.net with comcast id lzn81c0081YDfWL5D1VlZz; Mon, 28 Sep 2009 01:29:45 +0000
Received: from gwzPC ([124.120.229.49]) by OMTA20.westchester.pa.mail.comcast.net with comcast id m1Yv1c00L14bZwC3g1Z2EH; Mon, 28 Sep 2009 01:33:52 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
Cc: , , , , , , 
References:   
In-Reply-To: 
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 08:28:14 +0700
Message-ID: <00e701ca3fdb$15030e70$3f092b50$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E8_01CA4015.C161E670"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aco/i0q3aXmPsMIKQKmytfpn73cgjQAS6KIA
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

This is a multi-part message in MIME format.

------=_NextPart_000_00E8_01CA4015.C161E670
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com]  writes:

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

 

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

 

 

[BA] Are there specific uses of normative language in the document that you
believe are inappropriate?   

With the caveat that it's been some time since I read the draft, based upon
my last review I'd have to say virtually all the uses of RFC 2119
requirements language in the document are problematic.  I plan to go through
the note in depth again this week.  There is a lot of nonsense in it which I
had mistakenly considered innocuous blather, easily ignored (they are
"guidelines", after all).  However,  at some point during the final
discussions before the publication of RFC 5580 I realized that the document,
far from being a set of harmless suggestions on style, was in fact a club to
be used by pompous asses to keep people from getting real work done.  If you
recall, my major arguments against the attributes defined in 5580 were based
upon non-compliance w/the Design Guidelines document (yes, that would make
me one of those pompous asses & I would like to take this opportunity to
apologize to the authors of RFC 5580, the geopriv WG and the IESG for my
misguided behavior).  In fact, though, there was nothing technically wrong
with the geopriv attributes: they would have worked just fine, thank you.
Their only sin was deviation from a set of rules based upon a highly suspect
historical characterization of RADIUS development and a simplistic (if not
downright primitive processing model).  At any rate, removing the RFC 2119
language from the draft would go a long way toward making the document truly
harmless.


------=_NextPart_000_00E8_01CA4015.C161E670
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable































Bernard Aboba [mailto:bernard_aboba@hotmail.com] =
 writes:



WRT this document,
section 6 of RFC 2119 (sorry about the typo above) seems =
relevant:=




6.
Guidance in the use of these Imperatives



 =




  
Imperatives of the type defined in this memo must be used with =
care=




  
and sparingly.  In particular, they MUST only be used where it =
is=




  
actually required for interoperation or to limit behavior which =
has=




  
potential for causing harm (e.g., limiting retransmisssions)  =
For=




  
example, they must not be used to try to impose a particular =
method=




  
on implementors where the method is not required for=




  
interoperability.=




 



 



[BA]
Are there specific uses of normative language in the document that you =
believe
are inappropriate?   



With the caveat that it’s been some time since I =
read the
draft, based upon my last review I’d have to say virtually all the =
uses
of RFC 2119 requirements language in the document are problematic.  =
I plan
to go through the note in depth again this week.  There is a lot of
nonsense in it which I had mistakenly considered innocuous blather, =
easily
ignored (they are “guidelines”, after all).  However, =
 at
some point during the final discussions before the publication of RFC =
5580 I realized
that the document, far from being a set of harmless suggestions on =
style, was in
fact a club to be used by pompous asses to keep people from getting real =
work
done.  If you recall, my major arguments against the attributes =
defined in
5580 were based upon non-compliance w/the Design Guidelines document =
(yes, that
would make me one of those pompous asses & I would like to take this
opportunity to apologize to the authors of RFC 5580, the geopriv WG and =
the
IESG for my misguided behavior).  In fact, though, there was =
nothing
technically wrong with the geopriv attributes: they would have worked =
just
fine, thank you.  Their only sin was deviation from a set of rules =
based
upon a highly suspect historical characterization of RADIUS development =
and a
simplistic (if not downright primitive processing model).  At any =
rate,
removing the RFC 2119 language from the draft would go a long way toward =
making
the document truly harmless.
























------=_NextPart_000_00E8_01CA4015.C161E670--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 20:32:21 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E553A6832 for ; Sun, 27 Sep 2009 20:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.246
X-Spam-Level: 
X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JeemLWJY2Tu for ; Sun, 27 Sep 2009 20:32:20 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED27E3A67FE for ; Sun, 27 Sep 2009 20:32:19 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms6x6-0005Ef-B3 for radiusext-data0@psg.com; Mon, 28 Sep 2009 03:31:04 +0000
Received: from [192.160.6.148] (helo=hoemail1.alcatel.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms6ww-0005Ds-Ib for radiusext@ops.ietf.org; Mon, 28 Sep 2009 03:31:02 +0000
Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id n8S3UlkN022115; Sun, 27 Sep 2009 22:30:47 -0500 (CDT)
Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id n8S3UijV009534; Sun, 27 Sep 2009 22:30:45 -0500 (CDT)
Received: from sgsinsbhs01.ad4.ad.alcatel.com (sgsinsbhs01.ap.lucent.com [135.254.109.34]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n8S3KiZP025960; Mon, 28 Sep 2009 11:20:45 +0800
Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.30]) by sgsinsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 11:30:41 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 11:30:40 +0800
Message-ID: <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPv6 Address Option
Thread-Index: Aco/r6lnlH3obrcVTzmcMbi44RLwowAN1UIw
References:  <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>  
From: "MILES DAVID" 
To: "Bernard Aboba" , , , "David B. Nelson" 
Cc: , "Mark Townsley" 
X-OriginalArrivalTime: 28 Sep 2009 03:30:41.0341 (UTC) FILETIME=[0E034ED0:01CA3FEC]
X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27
X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Hi Bernard,

My email was simply an opportunity to prompt continued discussions from
Stockholm (things had been somewhat quiet).

To the question of tagged AVP,  your suggested rewording of
radext-design-07 :

For these reasons, the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types,
   it is RECOMMENDED that:
     =20
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present;=20

        * The design make no assumption about the content of the
          data within tagged attributes." =20

to require new AVP which implement tagged values must treat them as a
fixed/mandatory is to me the best approach _if_ it is decided that these
AVP should not fall under the guidelines of radext-extended-attributes.
My opinion is that radext-design-07 should be updated to include the
proposed text above. After that modification I believe the current text
in ipv6-access-01 around tags:

The Tag field is mandatory.  The Tag
      field values are greater than 0x00.

 Is sufficient to allow the adoption of this draft.

I see no other outstanding issues in the minutes or on the RADEXT issues
list for draft-lourdelet-radext-ipv6-access. Should I post your proposed
text as an issue to the list for tracking?


Cheers,

-David





--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 22:47:05 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA27B3A6810 for ; Sun, 27 Sep 2009 22:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level: 
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RohhTZm+NLWo for ; Sun, 27 Sep 2009 22:47:05 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C18AF3A67D2 for ; Sun, 27 Sep 2009 22:47:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms90X-000GGU-L3 for radiusext-data0@psg.com; Mon, 28 Sep 2009 05:42:45 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms90O-000GFO-L3 for radiusext@ops.ietf.org; Mon, 28 Sep 2009 05:42:43 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 190D712345DC; Mon, 28 Sep 2009 07:42:33 +0200 (CEST)
Message-ID: <4AC04CC8.2030609@deployingradius.com>
Date: Mon, 28 Sep 2009 07:42:32 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: MILES DAVID 
CC: Bernard Aboba , sarikaya@ieee.org,  radiusext@ops.ietf.org, "David B. Nelson" ,  roberta.maglione@telecomitalia.it, Mark Townsley 
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>   <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com>
In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

MILES DAVID wrote:
> I see no other outstanding issues in the minutes or on the RADEXT issues
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 23:07:31 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4493A6807 for ; Sun, 27 Sep 2009 23:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.963
X-Spam-Level: 
X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+07vGWr6zVb for ; Sun, 27 Sep 2009 23:07:30 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEA253A67F7 for ; Sun, 27 Sep 2009 23:07:30 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms9NJ-000INn-7O for radiusext-data0@psg.com; Mon, 28 Sep 2009 06:06:17 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms9N0-000IMC-Th for radiusext@ops.ietf.org; Mon, 28 Sep 2009 06:06:15 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 1901812345DC; Mon, 28 Sep 2009 08:05:58 +0200 (CEST)
Message-ID: <4AC05245.4010406@deployingradius.com>
Date: Mon, 28 Sep 2009 08:05:57 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'Bernard Aboba' , radiusext@ops.ietf.org
Subject: Re: IPv6 Address Option
References:   <008901ca3f50$a322c960$e9685c20$@net>
In-Reply-To: <008901ca3f50$a322c960$e9685c20$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
> Somebody should note (might as well be me) that since the 1) the
> document is not a protocol specification & 2) the intended status is
> BCP, the use of RFC 2118 keywords is inappropriate to begin with.

  Here's a list of RFCs that:

    (a) are Status: BCP
    (b) have the word "guidelines" in their title
    (c) use RFC 2119 keywords
    (d) are relatively recent

	http://tools.ietf.org/html/rfc3470

	http://tools.ietf.org/html/rfc3552

	http://tools.ietf.org/html/rfc4107

	http://tools.ietf.org/html/rfc4181

	http://tools.ietf.org/html/rfc4395

	http://tools.ietf.org/html/rfc5226

	http://tools.ietf.org/html/rfc5405

	http://tools.ietf.org/html/rfc5625

  That's 8 documents in about 5 minutes of work.  I think your claim has
been proven false.  The design guidelines document is following the
current practice of the IETF.  The only way to disprove this is outright
denial.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 23:23:15 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576913A680E for ; Sun, 27 Sep 2009 23:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.152
X-Spam-Level: 
X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKCJq5ZMCEQe for ; Sun, 27 Sep 2009 23:23:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38D4E3A67EA for ; Sun, 27 Sep 2009 23:23:14 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms9cF-000JmJ-9j for radiusext-data0@psg.com; Mon, 28 Sep 2009 06:21:43 +0000
Received: from [192.160.6.148] (helo=hoemail1.alcatel.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms9c5-000JlT-CL for radiusext@ops.ietf.org; Mon, 28 Sep 2009 06:21:40 +0000
Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id n8S6Kx3e020926; Mon, 28 Sep 2009 01:20:59 -0500 (CDT)
Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id n8S6Kvmn007708; Mon, 28 Sep 2009 01:20:58 -0500 (CDT)
Received: from sgsinsbhs01.ad4.ad.alcatel.com (sgsinsbhs01.ap.lucent.com [135.254.109.34]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id n8S6AucH016932; Mon, 28 Sep 2009 14:10:58 +0800
Received: from SGSINSMBS02.ad4.ad.alcatel.com ([135.254.109.30]) by sgsinsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 14:20:54 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:20:54 +0800
Message-ID: <986DCE2E44129444B6435ABE8C9E424D02DC138C@SGSINSMBS02.ad4.ad.alcatel.com>
In-Reply-To: <4AC04CC8.2030609@deployingradius.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPv6 Address Option
Thread-Index: Aco//pJhCvlaUqf8TuayIKdQqUPnJQAApbhA
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>   <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com> <4AC04CC8.2030609@deployingradius.com>
From: "MILES DAVID" 
To: "Alan DeKok" 
Cc: "Bernard Aboba" , , , "David B. Nelson" , , "Mark Townsley" 
X-OriginalArrivalTime: 28 Sep 2009 06:20:54.0709 (UTC) FILETIME=[D5A79650:01CA4003]
X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27
X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Sorry Alan,

I missed that one.

My comments on each point:

>Uplink-IPv6-Address instead of IPv6-Address
	I know the supporting text says "is assigned to the uplink of
the user equipment" but uplink may be confusing (the uplink of what) -
Peer/Subscriber/Host-IPv6-Address perhaps?


>IPv6-Route-Option-Preference
	Per your review - I too agree that a signed integer is somewhat
confusing however this is a direct copy of a DHCP option from RFC 4191:
Prf (Default Router Preference)
            2-bit signed integer.  Indicates whether to prefer this
            router over other default routers.  If the Router Lifetime
            is zero, the preference value MUST be set to (00) by the
            sender and MUST be ignored by the receiver.  If the Reserved
            (10) value is received, the receiver MUST treat the value as
            if it were (00).

  Preference values are encoded as a two-bit signed integer, as
   follows:

      01      High
      00      Medium (default)
      11      Low
      10      Reserved - MUST NOT be sent



> IPv6-Route-Option-Lifetime:
> Auth-IPv6-Prefix-Valid-Lifetime:
>=20
>   Defining a tag field *and* a 32-bit integer means that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section 3.1 for the historical definition.
>=20
>   It would seem to be OK to have a 24-bit lifetime.  That would allow
> everyone to use this attribute by simply updating their dictionaries,
> rather than writing new code to handle a new format.

Again these 32-bit values are straight out of RFC 4191 and there is a
requirement to support a value of infinity (0xffffffff). I think you
could get away with a 24-bit value and a special recognition of
infinity, but it is not desirable. If we adopt a fixed tag definition
per Bernard's suggestion, do we still have a problem?

=20
> Prefix-Lifetime-Service-Type
Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
integer. IMO this is not a big change one way or another - I have no
objection to changing this.



Cheers,

-David


-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.com]=20
Sent: Monday, 28 September 2009 3:13 PM
To: MILES DAVID
Cc: Bernard Aboba; sarikaya@ieee.org; radiusext@ops.ietf.org; David B.
Nelson; roberta.maglione@telecomitalia.it; Mark Townsley
Subject: Re: IPv6 Address Option

MILES DAVID wrote:
> I see no other outstanding issues in the minutes or on the RADEXT
issues
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Sun Sep 27 23:38:13 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F543A67F2 for ; Sun, 27 Sep 2009 23:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.95
X-Spam-Level: 
X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlT04Y4CS9JI for ; Sun, 27 Sep 2009 23:38:12 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C38823A6833 for ; Sun, 27 Sep 2009 23:38:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms9qe-000La8-KO for radiusext-data0@psg.com; Mon, 28 Sep 2009 06:36:36 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ms9qV-000LZG-1D for radiusext@ops.ietf.org; Mon, 28 Sep 2009 06:36:34 +0000
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D4EC212345DC; Mon, 28 Sep 2009 08:36:25 +0200 (CEST)
Message-ID: <4AC05969.7060400@deployingradius.com>
Date: Mon, 28 Sep 2009 08:36:25 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: MILES DAVID 
CC: Bernard Aboba , sarikaya@ieee.org,  radiusext@ops.ietf.org, "David B. Nelson" ,  roberta.maglione@telecomitalia.it, Mark Townsley 
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>   <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com> <4AC04CC8.2030609@deployingradius.com> <986DCE2E44129444B6435ABE8C9E424D02DC138C@SGSINSMBS02.ad4.ad.alcatel.com>
In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D02DC138C@SGSINSMBS02.ad4.ad.alcatel.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

MILES DAVID wrote:
>> Uplink-IPv6-Address instead of IPv6-Address
> 	I know the supporting text says "is assigned to the uplink of
> the user equipment" but uplink may be confusing (the uplink of what) -
> Peer/Subscriber/Host-IPv6-Address perhaps?

  Just something more specific than "IPv6-Address".  There are a lot of
possible uses for IPv6 addresses.  Having an attribute named just
"IPv6-Address" will be confusing.

> 
>> IPv6-Route-Option-Preference
> 	Per your review - I too agree that a signed integer is somewhat
> confusing however this is a direct copy of a DHCP option from RFC 4191:

  OK.  Is this attribute intended to transport that DHCP option, or to
mirror the functionality?

  There are no signed integers in RADIUS, and 16 bit integers are not
recommended.  I would suggest instead that the RADIUS definition of the
attribute be "2 octets", and that the definition refers to the
appropriate section of RFC 4191.

  i.e. leave the practical use of the attribute unchanged.  But change
the definition to refer to another specification, rather than
duplicating the definition here.

>> IPv6-Route-Option-Lifetime:
>> Auth-IPv6-Prefix-Valid-Lifetime:
...
> Again these 32-bit values are straight out of RFC 4191 and there is a
> requirement to support a value of infinity (0xffffffff). I think you
> could get away with a 24-bit value and a special recognition of
> infinity, but it is not desirable. If we adopt a fixed tag definition
> per Bernard's suggestion, do we still have a problem?

  It's still a new data type, but I think the alternatives would be worse.

>> Prefix-Lifetime-Service-Type
> Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
> integer. IMO this is not a big change one way or another - I have no
> objection to changing this.

  OK.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep 28 00:08:19 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078FE3A68CE for ; Mon, 28 Sep 2009 00:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Level: 
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2SOU8fRzoby for ; Mon, 28 Sep 2009 00:08:18 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 234723A68B9 for ; Mon, 28 Sep 2009 00:08:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsAHr-0004KY-0v for radiusext-data0@psg.com; Mon, 28 Sep 2009 07:04:43 +0000
Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsAHb-00049l-TL for radiusext@ops.ietf.org; Mon, 28 Sep 2009 07:04:40 +0000
Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id m73c1c0030bG4ec5474UBE; Mon, 28 Sep 2009 07:04:28 +0000
Received: from gwzPC ([124.122.163.108]) by OMTA03.westchester.pa.mail.comcast.net with comcast id m7491c0042LeCWs3P74Eva; Mon, 28 Sep 2009 07:04:26 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'Bernard Aboba'" , 
References:   <008901ca3f50$a322c960$e9685c20$@net> <4AC05245.4010406@deployingradius.com>
In-Reply-To: <4AC05245.4010406@deployingradius.com>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:03:40 +0700
Message-ID: <001c01ca4009$d90f6ab0$8b2e4010$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcpAAcD2Wq9KlphZSM+pbgyzl7ZAxAABQ/bA
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
> > Somebody should note (might as well be me) that since the 1) the
> > document is not a protocol specification & 2) the intended status is
> > BCP, the use of RFC 2118 keywords is inappropriate to begin with.
> 
>   Here's a list of RFCs that:
> 
>     (a) are Status: BCP
>     (b) have the word "guidelines" in their title
>     (c) use RFC 2119 keywords
>     (d) are relatively recent
> 
> 	http://tools.ietf.org/html/rfc3470
> 
> 	http://tools.ietf.org/html/rfc3552
> 
> 	http://tools.ietf.org/html/rfc4107
> 
> 	http://tools.ietf.org/html/rfc4181
> 
> 	http://tools.ietf.org/html/rfc4395
> 
> 	http://tools.ietf.org/html/rfc5226
> 
> 	http://tools.ietf.org/html/rfc5405
> 
> 	http://tools.ietf.org/html/rfc5625
> 
>   That's 8 documents in about 5 minutes of work.  I think your claim
> has
> been proven false.  The design guidelines document is following the
> current practice of the IETF.  The only way to disprove this is
> outright
> denial.

Speaking of which, perhaps you would like to address section 6 of RFC 2119.
Glad you've decided to do a little research once in a while, BTW ;-): you
have provided a treasure trove of material for RFC Errata.

> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep 28 00:22:00 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5E928C0DF for ; Mon, 28 Sep 2009 00:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Level: 
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at83WjMPlD20 for ; Mon, 28 Sep 2009 00:21:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C00228C0D0 for ; Mon, 28 Sep 2009 00:21:59 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsAXp-000DL3-U0 for radiusext-data0@psg.com; Mon, 28 Sep 2009 07:21:13 +0000
Received: from [76.96.27.212] (helo=QMTA14.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsAXf-000DIp-Sj for radiusext@ops.ietf.org; Mon, 28 Sep 2009 07:21:11 +0000
Received: from OMTA24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id m7LJ1c0021zF43QAE7M0WY; Mon, 28 Sep 2009 07:21:00 +0000
Received: from gwzPC ([124.122.163.108]) by OMTA24.emeryville.ca.mail.comcast.net with comcast id m7R31c0032LeCWs8k7R8EX; Mon, 28 Sep 2009 07:25:31 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" , "'MILES DAVID'" 
Cc: "'Bernard Aboba'" , , , "'David B. Nelson'" , , "'Mark Townsley'" 
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>   <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com> <4AC04CC8.2030609@deployingradius.com> <986DCE2E44129444B6435ABE8C9E424D02DC138C@SGSINSMBS02.ad4.ad.alcatel.com> <4AC05969.7060400@deployingradius.com>
In-Reply-To: <4AC05969.7060400@deployingradius.com>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:20:00 +0700
Message-ID: <001d01ca400c$2816ab80$78440280$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcpABmtwBdPN6j9zSAi5ICst7Be+rAAA+1QQ
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Alan DeKok [aland@destroyingradius.com] writes:

> MILES DAVID wrote:
> >> Uplink-IPv6-Address instead of IPv6-Address
> > 	I know the supporting text says "is assigned to the uplink of
> > the user equipment" but uplink may be confusing (the uplink of what)
> -
> > Peer/Subscriber/Host-IPv6-Address perhaps?
> 
>   Just something more specific than "IPv6-Address".  There are a lot of
> possible uses for IPv6 addresses.  Having an attribute named just
> "IPv6-Address" will be confusing.

Or useful; maybe they're the same thing?

> 
> >
> >> IPv6-Route-Option-Preference
> > 	Per your review - I too agree that a signed integer is somewhat
> > confusing however this is a direct copy of a DHCP option 

I think it's actually from a Router Advertisement message, but no matter.

> from RFC 4191:
> 
>   OK.  Is this attribute intended to transport that DHCP option, or to
> mirror the functionality?
> 
>   There are no signed integers in RADIUS, and 16 bit integers are not
> recommended.  I would suggest instead that the RADIUS definition of the
> attribute be "2 octets", and that the definition refers to the
> appropriate section of RFC 4191.

Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
single octet.

> 
>   i.e. leave the practical use of the attribute unchanged.  But change
> the definition to refer to another specification, rather than
> duplicating the definition here.

That's a fine idea.

...

> >> Prefix-Lifetime-Service-Type
> > Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
> > integer. IMO this is not a big change one way or another - I have no
> > objection to changing this.

Again, a single octet should suffice, no?

...


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep 28 00:39:44 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3799C3A686A for ; Mon, 28 Sep 2009 00:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.973
X-Spam-Level: 
X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWTBz2uB1+Ys for ; Mon, 28 Sep 2009 00:39:43 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36C833A6844 for ; Mon, 28 Sep 2009 00:39:43 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsAos-000M6c-7b for radiusext-data0@psg.com; Mon, 28 Sep 2009 07:38:50 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsAoh-000M27-Ch for radiusext@ops.ietf.org; Mon, 28 Sep 2009 07:38:47 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 64BBD12345DC; Mon, 28 Sep 2009 09:38:38 +0200 (CEST)
Message-ID: <4AC067FE.4030808@deployingradius.com>
Date: Mon, 28 Sep 2009 09:38:38 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'Bernard Aboba' , radiusext@ops.ietf.org
Subject: Re: IPv6 Address Option
References:   <008901ca3f50$a322c960$e9685c20$@net> <4AC05245.4010406@deployingradius.com> <001c01ca4009$d90f6ab0$8b2e4010$@net>
In-Reply-To: <001c01ca4009$d90f6ab0$8b2e4010$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
> Speaking of which, perhaps you would like to address section 6 of RFC 2119.

  You haven't pointed out which portions of the design guidelines
document violate that section.  You have had multiple opportunities to
do so.

  I don't see why I should address non-existent issues.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep 28 01:50:15 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07573A6873 for ; Mon, 28 Sep 2009 01:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Level: 
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2unltPGnlhwT for ; Mon, 28 Sep 2009 01:50:10 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D89E03A67F1 for ; Mon, 28 Sep 2009 01:50:09 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsBtw-000HII-N4 for radiusext-data0@psg.com; Mon, 28 Sep 2009 08:48:08 +0000
Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsBtk-000HFd-9T for radiusext@ops.ietf.org; Mon, 28 Sep 2009 08:48:05 +0000
Received: from OMTA18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id m8nw1c0011bwxycA58nwRr; Mon, 28 Sep 2009 08:47:56 +0000
Received: from gwzPC ([124.122.163.108]) by OMTA18.emeryville.ca.mail.comcast.net with comcast id m8t81c0052LeCWs8e8tCGe; Mon, 28 Sep 2009 08:53:24 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'Bernard Aboba'" , 
References:   <008901ca3f50$a322c960$e9685c20$@net> <4AC05245.4010406@deployingradius.com> <001c01ca4009$d90f6ab0$8b2e4010$@net> <4AC067FE.4030808@deployingradius.com>
In-Reply-To: <4AC067FE.4030808@deployingradius.com>
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 15:47:08 +0700
Message-ID: <002201ca4018$4cce9440$e66bbcc0$@net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01CA4052.F92D6C40"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcpADrOTp/TicD3oRs++sbmBV1NyhwACP66w
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01CA4052.F92D6C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto:aland@deployingradius.com] writes:
> > Speaking of which, perhaps you would like to address section 6 of RFC
> 2119.
> 
>   You haven't pointed out which portions of the design guidelines
> document violate that section.  You have had multiple opportunities to
> do so.

See attachment.

> 
>   I don't see why I should address non-existent issues.
> 
>   Alan DeKok.

------=_NextPart_000_0023_01CA4052.F92D6C40
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

Received: from psg.com ([147.28.0.62])
	by IMTA26.emeryville.ca.mail.comcast.net with comcast
	id m1bc1c00u1LFiyT0S1bdCG; Mon, 28 Sep 2009 01:35:39 +0000
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from )
	id 1Ms53t-000LGI-Mq
	for radiusext-data0@psg.com; Mon, 28 Sep 2009 01:29:57 +0000
Received: from [76.96.59.243] (helo=QMTA13.westchester.pa.mail.comcast.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from )
	id 1Ms53i-000LFH-5r
	for radiusext@ops.ietf.org; Mon, 28 Sep 2009 01:29:55 +0000
Received: from imta26.emeryville.ca.mail.comcast.net (LHLO
 IMTA26.emeryville.ca.mail.comcast.net) (76.96.30.79) by
 sz0087.ev.mail.comcast.net with LMTP; Mon, 28 Sep 2009 01:35:39 +0000 (UTC)
Received: from gwzPC ([124.120.229.49])
	by OMTA20.westchester.pa.mail.comcast.net with comcast
	id m1Yv1c00L14bZwC3g1Z2EH; Mon, 28 Sep 2009 01:33:52 +0000
Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71])
	by QMTA13.westchester.pa.mail.comcast.net with comcast
	id lzn81c0081YDfWL5D1VlZz; Mon, 28 Sep 2009 01:29:45 +0000
Return-Path: 
From: "Glen Zorn" 
Sender: 
To: "'Bernard Aboba'" 
Cc: ,
	,
	,
	,
	,
	,
	
References:   
In-Reply-To: 
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 08:28:14 +0700
Message-ID: <00e701ca3fdb$15030e70$3f092b50$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01CA4052.F92D1E20"
X-Mailer: Microsoft Office Outlook 12.0
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,	RDNS_NONE autolearn=no version=3.2.5
Thread-Index: Aco/i0q3aXmPsMIKQKmytfpn73cgjQAS6KIA
Content-Language: en-us
X-Authority-Analysis: v=1.0 c=1 a=RTLZkadmLlh5NdvcQZkdJA==:17 a=69EAbJreAAAA:8 a=5qO9ka6rXXjxde1-UtQA:9 a=gI16K7ckjlo9FLWOiLeawOZkztUA:4 a=EfJqPEOeqlMA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Ds7fev4g2VRAc5b2T6kA:9 a=R3SAO3oMq3M80DiQXUEA:7 a=3NTFqp_U0Y2X103m7LfJIx-CgecA:4
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on psg.com
X-Message-Flag: Follow up

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01CA4052.F92D1E20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com]  writes:

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

 

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

 

 

[BA] Are there specific uses of normative language in the document that you
believe are inappropriate?   

With the caveat that it's been some time since I read the draft, based upon
my last review I'd have to say virtually all the uses of RFC 2119
requirements language in the document are problematic.  I plan to go through
the note in depth again this week.  There is a lot of nonsense in it which I
had mistakenly considered innocuous blather, easily ignored (they are
"guidelines", after all).  However,  at some point during the final
discussions before the publication of RFC 5580 I realized that the document,
far from being a set of harmless suggestions on style, was in fact a club to
be used by pompous asses to keep people from getting real work done.  If you
recall, my major arguments against the attributes defined in 5580 were based
upon non-compliance w/the Design Guidelines document (yes, that would make
me one of those pompous asses & I would like to take this opportunity to
apologize to the authors of RFC 5580, the geopriv WG and the IESG for my
misguided behavior).  In fact, though, there was nothing technically wrong
with the geopriv attributes: they would have worked just fine, thank you.
Their only sin was deviation from a set of rules based upon a highly suspect
historical characterization of RADIUS development and a simplistic (if not
downright primitive processing model).  At any rate, removing the RFC 2119
language from the draft would go a long way toward making the document truly
harmless.


------=_NextPart_000_001E_01CA4052.F92D1E20
Content-Type: text/html;
	boundary="----=_NextPart_000_00E8_01CA4015.C161E670";
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

































Bernard Aboba [mailto:bernard_aboba@hotmail.com] =
 writes:



WRT this document,
section 6 of RFC 2119 (sorry about the typo above) seems =
relevant:=




6.
Guidance in the use of these Imperatives



 =




  
Imperatives of the type defined in this memo must be used with =
care=




  
and sparingly.  In particular, they MUST only be used where it =
is=




  
actually required for interoperation or to limit behavior which =
has=




  
potential for causing harm (e.g., limiting retransmisssions)  =
For=




  
example, they must not be used to try to impose a particular =
method=




  
on implementors where the method is not required for=




  
interoperability.=




 



 



[BA]
Are there specific uses of normative language in the document that you =
believe
are inappropriate?   



With the caveat that it’s been some time since I =
read the
draft, based upon my last review I’d have to say virtually all the =
uses
of RFC 2119 requirements language in the document are problematic.  =
I plan
to go through the note in depth again this week.  There is a lot of
nonsense in it which I had mistakenly considered innocuous blather, =
easily
ignored (they are “guidelines”, after all).  However, =
 at
some point during the final discussions before the publication of RFC =
5580 I realized
that the document, far from being a set of harmless suggestions on =
style, was in
fact a club to be used by pompous asses to keep people from getting real =
work
done.  If you recall, my major arguments against the attributes =
defined in
5580 were based upon non-compliance w/the Design Guidelines document =
(yes, that
would make me one of those pompous asses & I would like to take this
opportunity to apologize to the authors of RFC 5580, the geopriv WG and =
the
IESG for my misguided behavior).  In fact, though, there was =
nothing
technically wrong with the geopriv attributes: they would have worked =
just
fine, thank you.  Their only sin was deviation from a set of rules =
based
upon a highly suspect historical characterization of RADIUS development =
and a
simplistic (if not downright primitive processing model).  At any =
rate,
removing the RFC 2119 language from the draft would go a long way toward =
making
the document truly harmless.
























------=_NextPart_000_001E_01CA4052.F92D1E20--

------=_NextPart_000_0023_01CA4052.F92D6C40--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep 28 03:12:13 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7713A67B2 for ; Mon, 28 Sep 2009 03:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.959
X-Spam-Level: 
X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2H3nbqKh15h for ; Mon, 28 Sep 2009 03:12:12 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95D603A6405 for ; Mon, 28 Sep 2009 03:12:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsD8Y-00028f-TF for radiusext-data0@psg.com; Mon, 28 Sep 2009 10:07:18 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsD8P-00027s-TG for radiusext@ops.ietf.org; Mon, 28 Sep 2009 10:07:17 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id EE22012345DC; Mon, 28 Sep 2009 11:30:58 +0200 (CEST)
Message-ID: <4AC08252.4070407@deployingradius.com>
Date: Mon, 28 Sep 2009 11:30:58 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'Bernard Aboba' , radiusext@ops.ietf.org
Subject: Re: IPv6 Address Option
References:   <008901ca3f50$a322c960$e9685c20$@net> <4AC05245.4010406@deployingradius.com> <001c01ca4009$d90f6ab0$8b2e4010$@net> <4AC067FE.4030808@deployingradius.com> <002201ca4018$4cce9440$e66bbcc0$@net>
In-Reply-To: <002201ca4018$4cce9440$e66bbcc0$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
>>   You haven't pointed out which portions of the design guidelines
>> document violate that section.  You have had multiple opportunities to
>> do so.
> 
> See attachment.

  I don't count "virtually all of the document is wrong" as a useful
comment.  It doesn't propose anything that can be done to the document
to correct the alleged flaws.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Mon Sep 28 08:10:30 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6628F3A6894 for ; Mon, 28 Sep 2009 08:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.987
X-Spam-Level: 
X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEI1NkKFIQVu for ; Mon, 28 Sep 2009 08:10:29 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4934E3A677D for ; Mon, 28 Sep 2009 08:10:28 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsHo8-000CmY-SE for radiusext-data0@psg.com; Mon, 28 Sep 2009 15:06:32 +0000
Received: from web111410.mail.gq1.yahoo.com ([67.195.15.186]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsHne-000Cjm-PT for radiusext@ops.ietf.org; Mon, 28 Sep 2009 15:06:22 +0000
Received: (qmail 43154 invoked by uid 60001); 28 Sep 2009 15:04:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254150291; bh=EqDuUyMcmVjnrLFcXWktD+82O+1X4qxTPVRuxpNqA/0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rnOXa8ne5BOwQP5aEWBLVn2bNlzFbJoxOQY/WKOfK4XyLljh+w7LenwqUcCJqrb5duB8OnTOUIAbBEiRV797AFgU8M4Na9tju4LQHIgpIthK9sQFHW2KFS4klLaHAgat/mfXcYiBXWO7yBsCIIGtmbpuB9POvhQkiW123N7mGEI=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WQw382KGwqgeW4sZr35ermEVNncGttqIEXnptQC9JxgIb9U+gMJGJ4rh4IioVMwa69+ktsXasyIRWomIqTeA+xnzggY9ALheG+CpZA8260SaX1BP581FbiFiZgQynoZfpNAbIQKeCpTl4Q32WuLhngzS42XPdygE8+AmozD9b+o=;
Message-ID: <802896.30207.qm@web111410.mail.gq1.yahoo.com>
X-YMail-OSG: ve5PB3MVM1m0S2teoccLa83WA3aginEl.HG_A_s4nSHHyOut1CANW7hLEUKGX2zMwyOOb8JVeIR7Dgt6FDlqDuiOwYAwLRmhY.y7r.Upj7vHhA10gi.gaTP3E50EvBUgCvxbchSAyqQEnNeu6q7vbF4a.vxUp71r4bAd23JJhMJe2cAubaErtTy4qHwopg0twTJW43MvXCWNl.Suvr7mE0ITQKTphPZxTr_7nSuYiNghrD2ryENNH4fVJvI.KRGn_jb_39SF3UTvXU01hzANWGqCcF.Vhh0kMhpNDOUBzPkW22GsT9En
Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Mon, 28 Sep 2009 08:04:51 PDT
X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>  
Date: Mon, 28 Sep 2009 08:04:51 -0700 (PDT)
From: Behcet Sarikaya 
Reply-To: Behcet Sarikaya 
Subject: Re: IPv6 Address Option
To: Bernard Aboba , sarikaya@ieee.org, david.miles@alcatel-lucent.com.au, "radiusext@ops.ietf.org" , "David B. Nelson" 
Cc: roberta.maglione@telecomitalia.it, Mark Townsley 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-226991051-1254150291=:30207"
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--0-226991051-1254150291=:30207
Content-Type: text/plain; charset=us-ascii

Hi Bernard,
  There is also this:

https://ops.ietf.org/lists/radiusext/2009/msg00371.html

Regards,

Behcet


>
>From: Bernard Aboba 
>To: sarikaya@ieee.org; david.miles@alcatel-lucent.com.au; "radiusext@ops.ietf.org" ; David B. Nelson 
>Cc: roberta.maglione@telecomitalia.it; Mark Townsley 
>Sent: Sunday, September 27, 2009 3:18:16 PM
>Subject: RE: IPv6 Address Option
>
> >
>> No. Several people replied. They just supported the call without any comments, but they promised to comment.
>
>In looking at the archive, these are the only people whose response indicated support of the document: 
>
>Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
>Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
>Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html
>
>Aside from these individuals, who else has indicated support for the document?  Please provide links to their emails. 
>
>>Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).
>
>The issue isn't how many editors the document has.  The issue is the pace at which the document has evolved in response to feedback.  
>
>The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.  If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.  Providing deadlines without engaged people doesn't help. 
>
>And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. 
>
>
>
>
>
>
>
>


      
--0-226991051-1254150291=:30207
Content-Type: text/html; charset=us-ascii


Hi Bernard,
  There is also this:

https://ops.ietf.org/lists/radiusext/2009/msg00371.html

Regards,

Behcet

From: Bernard Aboba <bernard_aboba@hotmail.com>
To: sarikaya@ieee.org; david.miles@alcatel-lucent.com.au; "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>;
 David B. Nelson <d.b.nelson@comcast.net>
Cc: roberta.maglione@telecomitalia.it; Mark Townsley <townsley@cisco.com>
Sent: Sunday, September 27, 2009 3:18:16 PM
Subject: RE: IPv6 Address Option







> No. Several people replied. They just supported the call without any comments, but they promised to comment.

In looking at the archive, these are the only people whose response indicated support of the document: 

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html

Aside from these individuals, who else has indicated support for the document?  Please provide links to their emails. 

>Well, we certainly would be happy to have David on board. However, I think the
 document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

The issue isn't how many editors the document has.  The issue is the pace at which the document has evolved in response to feedback.  

The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.  If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.  Providing deadlines without engaged people doesn't help. 

And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. 







 		 	   		  



      
--0-226991051-1254150291=:30207--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep 29 06:59:10 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB87F3A68AC for ; Tue, 29 Sep 2009 06:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.963
X-Spam-Level: 
X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPSq+7n7fLUv for ; Tue, 29 Sep 2009 06:59:10 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACC7B3A6AB1 for ; Tue, 29 Sep 2009 06:59:09 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsdBi-000CA5-CI for radiusext-data0@psg.com; Tue, 29 Sep 2009 13:56:18 +0000
Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsdBS-000C8p-U7 for radiusext@ops.ietf.org; Tue, 29 Sep 2009 13:56:10 +0000
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 2052912345DC; Tue, 29 Sep 2009 15:56:01 +0200 (CEST)
Message-ID: <4AC211F0.9010003@deployingradius.com>
Date: Tue, 29 Sep 2009 15:56:00 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  'Bernard Aboba' , sarikaya@ieee.org, radiusext@ops.ietf.org,  "'David B. Nelson'" , roberta.maglione@telecomitalia.it, 'Mark Townsley' 
Subject: Re: IPv6 Address Option
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>   <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com> <4AC04CC8.2030609@deployingradius.com> <986DCE2E44129444B6435ABE8C9E424D02DC138C@SGSINSMBS02.ad4.ad.alcatel.com> <4AC05969.7060400@deployingradius.com> <001d01ca400c$2816ab80$78440280$@net>
In-Reply-To: <001d01ca400c$2816ab80$78440280$@net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

Glen Zorn wrote:
> Alan DeKok [aland@destroyingradius.com] writes:
>>...  Having an attribute named just
>> "IPv6-Address" will be confusing.
> 
> Or useful; maybe they're the same thing?

  Sure, if we presume that RADIUS only ever transports one IPv6-address
attribute.  Why not call it IPv6-Address?

> Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
> single octet.

  Fine by me.

...
> Again, a single octet should suffice, no?

  Fine by me.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep 29 07:30:07 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E0528C163 for ; Tue, 29 Sep 2009 07:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.183
X-Spam-Level: *
X-Spam-Status: No, score=1.183 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAlHEBp3YP13 for ; Tue, 29 Sep 2009 07:30:06 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 806B728C15F for ; Tue, 29 Sep 2009 07:30:06 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Msdgh-000IzU-1K for radiusext-data0@psg.com; Tue, 29 Sep 2009 14:28:19 +0000
Received: from [65.55.116.44] (helo=blu0-omc1-s33.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MsdgX-000Iy7-At for radiusext@ops.ietf.org; Tue, 29 Sep 2009 14:28:16 +0000
Received: from BLU137-W34 ([65.55.116.9]) by blu0-omc1-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 07:28:09 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_4c741b3f-8be6-465d-bccd-1c78bbaee459_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: Mark Townsley 
CC: , , "radiusext@ops.ietf.org" , "David B. Nelson" , , 
Subject: Usage model and scenarios
Date: Tue, 29 Sep 2009 07:28:08 -0700
Importance: Normal
In-Reply-To: <4AC21460.6070702@cisco.com>
References: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>   <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com> <4AC04CC8.2030609@deployingradius.com> <986DCE2E44129444B6435ABE8C9E424D02DC138C@SGSINSMBS02.ad4.ad.alcatel.com> <4AC05969.7060400@deployingradius.com> <001d01ca400c$2816ab80$78440280$@net> <4AC211F0.9010003@deployingradius.com> <4AC21460.6070702@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Sep 2009 14:28:09.0029 (UTC) FILETIME=[11148F50:01CA4111]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_4c741b3f-8be6-465d-bccd-1c78bbaee459_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Mark Townsley wrote:

"Is this a wan interface IPv6 address=2C or a lan-side delegated prefix?
And=2C might we want both? Even a third that might be the management IPv6
address assigned to a loopback?



If the scope is far less here=2C that's fine with me=2C but in principle I
can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware
of (for running BFD or whatever kind of thing the BNG might want to do
with an RG) more than just one IPv6 address."

I think this is one of the issues that has confused members of the WG who h=
ave attempted to review the document. Overall=2C the  usage model underlyin=
g the document is unclear and this could potentially result in interoperabi=
lity problems.=20

For example=2C are we talking about prefix delegation=2C then presumably we=
 are looking to utilize the attributes defined in RFC 4818.=20

If we are not talking about prefix delegation=2C then are we utilizing the =
address assignment model of PPP IPv6CP or DHCPv6?  If it is IPv6CP=2C then =
it would not seem to make sense for the IPv6-Address in question to be that=
 of the client interface=2C since that is already determined by the attribu=
tes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-Id). =20

If we are utilizing the address assignment model of DHCPv6=2C then is the N=
AS acting as a DHCPv6 server?  Since RADIUS is spoken between a NAS and a R=
ADIUS server=2C if the DHCPv6 server does not reside on the NAS=2C then thi=
s raises questions about what entities are involved in the RADIUS protocol =
conversation=2C and whether authentication (or a Call Check) is taking plac=
e.=20

Outlining the specific scenarios that under consideration and the requireme=
nts for a solution would help greatly in promoting progress on this documen=
t.=20
 		 	   		  =

--_4c741b3f-8be6-465d-bccd-1c78bbaee459_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Mark Townsley wrote:

"Is this a wan interface IPv6 address=2C or a l=
an-side delegated prefix?
And=2C might we want both? Even a third that might be the management IPv6
address assigned to a loopback?



If the scope is far less here=2C that's fine with me=2C but in principle I
can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware
of (for running BFD or whatever kind of thing the BNG might want to do
with an RG) more than just one IPv6 address."

I think this is one of=
 the issues that has confused members of the WG who have attempted to revie=
w the document. Overall=2C the =3B usage model underlying the document =
is unclear and this could potentially result in interoperability problems. =


For example=2C are we talking about prefix delegation=2C then presu=
mably we are looking to utilize the attributes defined in RFC 4818. 
If we are not talking about prefix delegation=2C then are we utilizing the=
 address assignment model of PPP IPv6CP or DHCPv6? =3B If it is IPv6CP=
=2C then it would not seem to make sense for the IPv6-Address in question t=
o be that of the client interface=2C since that is already determined by th=
e attributes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-I=
d). =3B 

If we are utilizing the address assignment model of DHC=
Pv6=2C then is the NAS acting as a DHCPv6 server? =3B Since RADIUS is s=
poken between a NAS and a RADIUS server=2C if the DHCPv6 server does not re=
side on the NAS=2C then this raises questions about what entities are invol=
ved in the RADIUS protocol conversation=2C and whether authentication (or a=
 Call Check) is taking place. 

Outlining the specific scenarios that=
 under consideration and the requirements for a solution would help greatly=
 in promoting progress on this document. 
 		 	   		  
=

--_4c741b3f-8be6-465d-bccd-1c78bbaee459_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep 29 07:47:55 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B33C3A6ADE for ; Tue, 29 Sep 2009 07:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.442
X-Spam-Level: *
X-Spam-Status: No, score=1.442 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7WwYVTMOAhR for ; Tue, 29 Sep 2009 07:47:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 458C13A6876 for ; Tue, 29 Sep 2009 07:47:54 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Msdwt-000MJ5-Sx for radiusext-data0@psg.com; Tue, 29 Sep 2009 14:45:03 +0000
Received: from [65.55.116.17] (helo=blu0-omc1-s6.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Msdtt-000Lm5-Hp for radiusext@ops.ietf.org; Tue, 29 Sep 2009 14:43:35 +0000
Received: from BLU137-W12 ([65.55.116.9]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 07:41:57 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_841f9965-2847-440a-8666-ccc5cf86a392_"
X-Originating-IP: [24.19.160.219]
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: IPv6 support: potential approaches
Date: Tue, 29 Sep 2009 07:41:57 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Sep 2009 14:41:57.0009 (UTC) FILETIME=[FE984810:01CA4112]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

--_841f9965-2847-440a-8666-ccc5cf86a392_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


During the discussion of the tagging scheme proposed in draft-lourdelet=2C=
=20
the topic of new data types has come up.=20

This seems to be one of those situations where it would seem that we
are faced with choosing the lesser of 2 (or maybe 3) evils:

1. Creating a new tagging scheme=2C along with several new attributes=3B=20
2. Creating a complex (or opaque?) attribute to encapsulate all the items t=
hat could
potentially be sent in a router advertisement=3B=20
3. Creating a dependency on a generic=2C but not yet completed tagging
scheme (Extended Attributes).=20

Each of these choices requires new code on both the RADIUS client and serve=
r=2C
so that this would not appear to be a consideration.=20

In comparing choices number 1 and 3=2C  the third choice seems preferable i=
n that
it would amortize the pain of supporting new data types over a wider range =
of
uses.=20

However=2C it is not clear to me that either choices 1 or 3 are superior to=
 choice 2
in terms of total effort required=2C particularly if the route advertisemen=
t attribute
could be engineered as an opaque (string) attribute.  This would remove the=
 need
to add code on the RADIUS server.=20

Am I missing any potential choices or are the choices simpler than those pr=
ovided
above?=20




 		 	   		  =

--_841f9965-2847-440a-8666-ccc5cf86a392_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






During the discussion of the tagging scheme proposed in draft-lourdelet=2C =

the topic of new data types has come up. 

This seems to be one o=
f those situations where it would seem that we
are faced with choosing t=
he lesser of 2 (or maybe 3) evils:

1. Creating a new tagging scheme=
=2C along with several new attributes=3B 
2. Creating a complex (or opaq=
ue?) attribute to encapsulate all the items that could
potentially be se=
nt in a router advertisement=3B 
3. Creating a dependency on a generic=
=2C but not yet completed tagging
scheme (Extended Attributes). 

=
Each of these choices requires new code on both the RADIUS client and serve=
r=2C
so that this would not appear to be a consideration. 

In com=
paring choices number 1 and 3=2C =3B the third choice seems preferable =
in that
it would amortize the pain of supporting new data types over a w=
ider range of
uses. 

However=2C it is not clear to me that either=
 choices 1 or 3 are superior to choice 2
in terms of total effort requir=
ed=2C particularly if the route advertisement attribute
could be enginee=
red as an opaque (string) attribute. =3B This would remove the need
=
to add code on the RADIUS server. 

Am I missing any potential choice=
s or are the choices simpler than those provided
above? 



=
=

--_841f9965-2847-440a-8666-ccc5cf86a392_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

From owner-radiusext@ops.ietf.org  Tue Sep 29 09:04:35 2009
Return-Path: 
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B69E3A6AEA for ; Tue, 29 Sep 2009 09:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.547
X-Spam-Level: 
X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFvp7ad3o7OB for ; Tue, 29 Sep 2009 09:04:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 122FD3A6899 for ; Tue, 29 Sep 2009 09:04:34 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Msf93-000C0a-55 for radiusext-data0@psg.com; Tue, 29 Sep 2009 16:01:41 +0000
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Msf8t-000Bnb-6F for radiusext@ops.ietf.org; Tue, 29 Sep 2009 16:01:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=blourdel@cisco.com; l=1145; q=dns/txt; s=amsiport01001; t=1254240091; x=1255449691; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Benoit=20Lourdelet=20(blourdel)"=20|Subject:=20RE:=20Usage=20model=20and=20scenarios |Date:=20Tue,=2029=20Sep=202009=2018:01:24=20+0200 |Message-ID:=20<877805C876DB9243984870AAD14107625D1E68@XM B-AMS-103.cisco.com>|To:=20"Mark=20Townsley=20(townsley)" =20,=0D=0A=20=20=20=20=20=20=20=20"Ma glione=20Roberta"=20, =0D=0A=20=20=20=20=20=20=20=20"Bernard=20Aboba"=20|Cc:=20,=20,=0D=0A=20=20=20=20=20=20=20 =20,=20"David=20B.=20Nelson"=20,=0D=0A=20=20=20=20=20=20=20=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|In-Reply-To:=20|References: =20; bh=iMm+ML9R3o4gCYZkP6w0enZ0i02C/1ZRsjd+xt59IRk=; b=X2+bcObBiLtsudI6qdCP3akmKhuSlkN+YHyUWxTgtIlqLmAOpjO6rn8F w9fll/FjDKMDu14w4xuIf8Sb/j453FWKmLTKCpOJ4cD7jnBNExq3FN3+6 1lhZn7ZgSPDbGxQfLdpKWBPE9odaoKAEmiBqrXQAT0QwXgqtq5r2YxtoD Q=;
Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=blourdel@cisco.com
X-IronPort-AV: E=Sophos;i="4.44,474,1249257600";  d="scan'208";a="50520498"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Sep 2009 16:01:29 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8TG1TmZ027269; Tue, 29 Sep 2009 18:01:29 +0200
Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8TG1TBt023031; Tue, 29 Sep 2009 16:01:29 GMT
Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 18:01:29 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Usage model and scenarios
Date: Tue, 29 Sep 2009 18:01:24 +0200
Message-ID: <877805C876DB9243984870AAD14107625D1E68@XMB-AMS-103.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Usage model and scenarios
Thread-Index: AcpBGlz2J9Xcr44qTDeIxbFff9rDlgAAzHOQ
References: 
From: "Benoit Lourdelet (blourdel)" 
To: "Mark Townsley (townsley)" , "Maglione Roberta" , "Bernard Aboba" 
Cc: , , , "David B. Nelson" , 
X-OriginalArrivalTime: 29 Sep 2009 16:01:29.0287 (UTC) FILETIME=[1B181D70:01CA411E]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1145; t=1254240089; x=1255104089; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20Usage=20model=20and=20scenarios |Sender:=20; bh=iMm+ML9R3o4gCYZkP6w0enZ0i02C/1ZRsjd+xt59IRk=; b=dIqbEXQP9VuLbwmFGxrkun+BgVOTGoJTfsB8KX/pLiZM9FRC5fm+TfFMNQ Qd1z8n90MPB7ijKzQwlUxke0q+CZBt93pOkgeNOnHpdN/yy0zgtRxMj3W9qt t3vYHtWnlb;
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: 

If we restrict ourselves to the SP deployment "uplink-IPv6-address"
seems then the right term as already proposed. Letting aside the
loopback numbering problem.

I had in mind to extend a bit the field of applications and account for
Enterprise deployment on LAN where "uplink" is not a familiar term.

Benoit

-----Original Message-----
From: Mark Townsley (townsley)=20
Sent: Tuesday, September 29, 2009 5:35 PM
To: 'Maglione Roberta'; 'Bernard Aboba'
Cc: 'david.miles@alcatel-lucent.com.au'; 'sarikaya@ieee.org';
'radiusext@ops.ietf.org'; 'David B. Nelson'; 'ot@cisco.com'; Benoit
Lourdelet (blourdel)
Subject: RE: Usage model and scenarios


I can imagine the desire to have an ipv6 address on the wan link itself,
as well as one not associated with the physical interface, but a
"loopback" on the RG. If this is the former, I think it should be
labeled as such. Whether we need the latter is perhaps another
discussion. (in ipv4 of course we didn't have these luxuries of
assigning addresses to everything that might be addressable. Doesn't
mean ipv6 will evolve in the same manner.)




Sent from my mobile.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 

Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 29 Sep 2009 16:02:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=blourdel@cisco.com; l=1145; q=dns/txt; s=amsiport01001; t=1254240091; x=1255449691; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Benoit=20Lourdelet=20(blourdel)"=20|Subject:=20RE:=20Usage=20model=20and=20scenarios |Date:=20Tue,=2029=20Sep=202009=2018:01:24=20+0200 |Message-ID:=20<877805C876DB9243984870AAD14107625D1E68@XM B-AMS-103.cisco.com>|To:=20"Mark=20Townsley=20(townsley)" =20,=0D=0A=20=20=20=20=20=20=20=20"Ma glione=20Roberta"=20, =0D=0A=20=20=20=20=20=20=20=20"Bernard=20Aboba"=20|Cc:=20,=20,=0D=0A=20=20=20=20=20=20=20 =20,=20"David=20B.=20Nelson"=20,=0D=0A=20=20=20=20=20=20=20=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|In-Reply-To:=20|References: =20; bh=iMm+ML9R3o4gCYZkP6w0enZ0i02C/1ZRsjd+xt59IRk=; b=X2+bcObBiLtsudI6qdCP3akmKhuSlkN+YHyUWxTgtIlqLmAOpjO6rn8F w9fll/FjDKMDu14w4xuIf8Sb/j453FWKmLTKCpOJ4cD7jnBNExq3FN3+6 1lhZn7ZgSPDbGxQfLdpKWBPE9odaoKAEmiBqrXQAT0QwXgqtq5r2YxtoD Q=;
Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=blourdel@cisco.com
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Usage model and scenarios
Date: Tue, 29 Sep 2009 18:01:24 +0200
Message-ID: <877805C876DB9243984870AAD14107625D1E68@XMB-AMS-103.cisco.com>
Thread-Topic: Usage model and scenarios
Thread-Index: AcpBGlz2J9Xcr44qTDeIxbFff9rDlgAAzHOQ
From: "Benoit Lourdelet (blourdel)" 
To: "Mark Townsley (townsley)" , "Maglione Roberta" , "Bernard Aboba" 
Cc: , , , "David B. Nelson" , 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1145; t=1254240089; x=1255104089; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20Usage=20model=20and=20scenarios |Sender:=20; bh=iMm+ML9R3o4gCYZkP6w0enZ0i02C/1ZRsjd+xt59IRk=; b=dIqbEXQP9VuLbwmFGxrkun+BgVOTGoJTfsB8KX/pLiZM9FRC5fm+TfFMNQ Qd1z8n90MPB7ijKzQwlUxke0q+CZBt93pOkgeNOnHpdN/yy0zgtRxMj3W9qt t3vYHtWnlb;

If we restrict ourselves to the SP deployment "uplink-IPv6-address"
seems then the right term as already proposed. Letting aside the
loopback numbering problem.

I had in mind to extend a bit the field of applications and account for
Enterprise deployment on LAN where "uplink" is not a familiar term.

Benoit

-----Original Message-----
From: Mark Townsley (townsley)=20
Sent: Tuesday, September 29, 2009 5:35 PM
To: 'Maglione Roberta'; 'Bernard Aboba'
Cc: 'david.miles@alcatel-lucent.com.au'; 'sarikaya@ieee.org';
'radiusext@ops.ietf.org'; 'David B. Nelson'; 'ot@cisco.com'; Benoit
Lourdelet (blourdel)
Subject: RE: Usage model and scenarios


I can imagine the desire to have an ipv6 address on the wan link itself,
as well as one not associated with the physical interface, but a
"loopback" on the RG. If this is the former, I think it should be
labeled as such. Whether we need the latter is perhaps another
discussion. (in ipv4 of course we didn't have these luxuries of
assigning addresses to everything that might be addressable. Doesn't
mean ipv6 will evolve in the same manner.)




Sent from my mobile.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 29 Sep 2009 14:46:43 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_841f9965-2847-440a-8666-ccc5cf86a392_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: IPv6 support: potential approaches
Date: Tue, 29 Sep 2009 07:41:57 -0700
MIME-Version: 1.0

--_841f9965-2847-440a-8666-ccc5cf86a392_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


During the discussion of the tagging scheme proposed in draft-lourdelet=2C=
=20
the topic of new data types has come up.=20

This seems to be one of those situations where it would seem that we
are faced with choosing the lesser of 2 (or maybe 3) evils:

1. Creating a new tagging scheme=2C along with several new attributes=3B=20
2. Creating a complex (or opaque?) attribute to encapsulate all the items t=
hat could
potentially be sent in a router advertisement=3B=20
3. Creating a dependency on a generic=2C but not yet completed tagging
scheme (Extended Attributes).=20

Each of these choices requires new code on both the RADIUS client and serve=
r=2C
so that this would not appear to be a consideration.=20

In comparing choices number 1 and 3=2C  the third choice seems preferable i=
n that
it would amortize the pain of supporting new data types over a wider range =
of
uses.=20

However=2C it is not clear to me that either choices 1 or 3 are superior to=
 choice 2
in terms of total effort required=2C particularly if the route advertisemen=
t attribute
could be engineered as an opaque (string) attribute.  This would remove the=
 need
to add code on the RADIUS server.=20

Am I missing any potential choices or are the choices simpler than those pr=
ovided
above?=20




 		 	   		  =

--_841f9965-2847-440a-8666-ccc5cf86a392_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






During the discussion of the tagging scheme proposed in draft-lourdelet=2C =

the topic of new data types has come up. 

This seems to be one o=
f those situations where it would seem that we
are faced with choosing t=
he lesser of 2 (or maybe 3) evils:

1. Creating a new tagging scheme=
=2C along with several new attributes=3B 
2. Creating a complex (or opaq=
ue?) attribute to encapsulate all the items that could
potentially be se=
nt in a router advertisement=3B 
3. Creating a dependency on a generic=
=2C but not yet completed tagging
scheme (Extended Attributes). 

=
Each of these choices requires new code on both the RADIUS client and serve=
r=2C
so that this would not appear to be a consideration. 

In com=
paring choices number 1 and 3=2C =3B the third choice seems preferable =
in that
it would amortize the pain of supporting new data types over a w=
ider range of
uses. 

However=2C it is not clear to me that either=
 choices 1 or 3 are superior to choice 2
in terms of total effort requir=
ed=2C particularly if the route advertisement attribute
could be enginee=
red as an opaque (string) attribute. =3B This would remove the need
=
to add code on the RADIUS server. 

Am I missing any potential choice=
s or are the choices simpler than those provided
above? 



=


 		 	   		  

=

--_841f9965-2847-440a-8666-ccc5cf86a392_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 29 Sep 2009 14:28:39 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_4c741b3f-8be6-465d-bccd-1c78bbaee459_"
From: Bernard Aboba 
To: Mark Townsley 
CC: , , "radiusext@ops.ietf.org" , "David B. Nelson" , , 
Subject: Usage model and scenarios
Date: Tue, 29 Sep 2009 07:28:08 -0700
MIME-Version: 1.0

--_4c741b3f-8be6-465d-bccd-1c78bbaee459_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Mark Townsley wrote:

"Is this a wan interface IPv6 address=2C or a lan-side delegated prefix?
And=2C might we want both? Even a third that might be the management IPv6
address assigned to a loopback?



If the scope is far less here=2C that's fine with me=2C but in principle I
can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware
of (for running BFD or whatever kind of thing the BNG might want to do
with an RG) more than just one IPv6 address."

I think this is one of the issues that has confused members of the WG who h=
ave attempted to review the document. Overall=2C the  usage model underlyin=
g the document is unclear and this could potentially result in interoperabi=
lity problems.=20

For example=2C are we talking about prefix delegation=2C then presumably we=
 are looking to utilize the attributes defined in RFC 4818.=20

If we are not talking about prefix delegation=2C then are we utilizing the =
address assignment model of PPP IPv6CP or DHCPv6?  If it is IPv6CP=2C then =
it would not seem to make sense for the IPv6-Address in question to be that=
 of the client interface=2C since that is already determined by the attribu=
tes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-Id). =20

If we are utilizing the address assignment model of DHCPv6=2C then is the N=
AS acting as a DHCPv6 server?  Since RADIUS is spoken between a NAS and a R=
ADIUS server=2C if the DHCPv6 server does not reside on the NAS=2C then thi=
s raises questions about what entities are involved in the RADIUS protocol =
conversation=2C and whether authentication (or a Call Check) is taking plac=
e.=20

Outlining the specific scenarios that under consideration and the requireme=
nts for a solution would help greatly in promoting progress on this documen=
t.=20
 		 	   		  =

--_4c741b3f-8be6-465d-bccd-1c78bbaee459_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Mark Townsley wrote:

"Is this a wan interface IPv6 address=2C or a l=
an-side delegated prefix?
And=2C might we want both? Even a third that might be the management IPv6
address assigned to a loopback?



If the scope is far less here=2C that's fine with me=2C but in principle I
can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware
of (for running BFD or whatever kind of thing the BNG might want to do
with an RG) more than just one IPv6 address."

I think this is one of=
 the issues that has confused members of the WG who have attempted to revie=
w the document. Overall=2C the =3B usage model underlying the document =
is unclear and this could potentially result in interoperability problems. =


For example=2C are we talking about prefix delegation=2C then presu=
mably we are looking to utilize the attributes defined in RFC 4818. 
If we are not talking about prefix delegation=2C then are we utilizing the=
 address assignment model of PPP IPv6CP or DHCPv6? =3B If it is IPv6CP=
=2C then it would not seem to make sense for the IPv6-Address in question t=
o be that of the client interface=2C since that is already determined by th=
e attributes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-I=
d). =3B 

If we are utilizing the address assignment model of DHC=
Pv6=2C then is the NAS acting as a DHCPv6 server? =3B Since RADIUS is s=
poken between a NAS and a RADIUS server=2C if the DHCPv6 server does not re=
side on the NAS=2C then this raises questions about what entities are invol=
ved in the RADIUS protocol conversation=2C and whether authentication (or a=
 Call Check) is taking place. 

Outlining the specific scenarios that=
 under consideration and the requirements for a solution would help greatly=
 in promoting progress on this document. 
 		 	   		  
=

--_4c741b3f-8be6-465d-bccd-1c78bbaee459_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 29 Sep 2009 13:57:20 +0000
Message-ID: <4AC211F0.9010003@deployingradius.com>
Date: Tue, 29 Sep 2009 15:56:00 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  'Bernard Aboba' , sarikaya@ieee.org, radiusext@ops.ietf.org,  "'David B. Nelson'" , roberta.maglione@telecomitalia.it, 'Mark Townsley' 
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Alan DeKok [aland@destroyingradius.com] writes:
>>...  Having an attribute named just
>> "IPv6-Address" will be confusing.
> 
> Or useful; maybe they're the same thing?

  Sure, if we presume that RADIUS only ever transports one IPv6-address
attribute.  Why not call it IPv6-Address?

> Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
> single octet.

  Fine by me.

...
> Again, a single octet should suffice, no?

  Fine by me.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 15:07:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254150291; bh=EqDuUyMcmVjnrLFcXWktD+82O+1X4qxTPVRuxpNqA/0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rnOXa8ne5BOwQP5aEWBLVn2bNlzFbJoxOQY/WKOfK4XyLljh+w7LenwqUcCJqrb5duB8OnTOUIAbBEiRV797AFgU8M4Na9tju4LQHIgpIthK9sQFHW2KFS4klLaHAgat/mfXcYiBXWO7yBsCIIGtmbpuB9POvhQkiW123N7mGEI=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WQw382KGwqgeW4sZr35ermEVNncGttqIEXnptQC9JxgIb9U+gMJGJ4rh4IioVMwa69+ktsXasyIRWomIqTeA+xnzggY9ALheG+CpZA8260SaX1BP581FbiFiZgQynoZfpNAbIQKeCpTl4Q32WuLhngzS42XPdygE8+AmozD9b+o=;
Message-ID: <802896.30207.qm@web111410.mail.gq1.yahoo.com>
Date: Mon, 28 Sep 2009 08:04:51 -0700 (PDT)
From: Behcet Sarikaya 
Reply-To: Behcet Sarikaya 
Subject: Re: IPv6 Address Option
To: Bernard Aboba , sarikaya@ieee.org, david.miles@alcatel-lucent.com.au, "radiusext@ops.ietf.org" , "David B. Nelson" 
Cc: roberta.maglione@telecomitalia.it, Mark Townsley 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-226991051-1254150291=:30207"

--0-226991051-1254150291=:30207
Content-Type: text/plain; charset=us-ascii

Hi Bernard,
  There is also this:

https://ops.ietf.org/lists/radiusext/2009/msg00371.html

Regards,

Behcet


>
>From: Bernard Aboba 
>To: sarikaya@ieee.org; david.miles@alcatel-lucent.com.au; "radiusext@ops.ietf.org" ; David B. Nelson 
>Cc: roberta.maglione@telecomitalia.it; Mark Townsley 
>Sent: Sunday, September 27, 2009 3:18:16 PM
>Subject: RE: IPv6 Address Option
>
> >
>> No. Several people replied. They just supported the call without any comments, but they promised to comment.
>
>In looking at the archive, these are the only people whose response indicated support of the document: 
>
>Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
>Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
>Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html
>
>Aside from these individuals, who else has indicated support for the document?  Please provide links to their emails. 
>
>>Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).
>
>The issue isn't how many editors the document has.  The issue is the pace at which the document has evolved in response to feedback.  
>
>The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.  If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.  Providing deadlines without engaged people doesn't help. 
>
>And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. 
>
>
>
>
>
>
>
>


      
--0-226991051-1254150291=:30207
Content-Type: text/html; charset=us-ascii


Hi Bernard,
  There is also this:

https://ops.ietf.org/lists/radiusext/2009/msg00371.html

Regards,

Behcet

From: Bernard Aboba <bernard_aboba@hotmail.com>
To: sarikaya@ieee.org; david.miles@alcatel-lucent.com.au; "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>;
 David B. Nelson <d.b.nelson@comcast.net>
Cc: roberta.maglione@telecomitalia.it; Mark Townsley <townsley@cisco.com>
Sent: Sunday, September 27, 2009 3:18:16 PM
Subject: RE: IPv6 Address Option







> No. Several people replied. They just supported the call without any comments, but they promised to comment.

In looking at the archive, these are the only people whose response indicated support of the document: 

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html

Aside from these individuals, who else has indicated support for the document?  Please provide links to their emails. 

>Well, we certainly would be happy to have David on board. However, I think the
 document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

The issue isn't how many editors the document has.  The issue is the pace at which the document has evolved in response to feedback.  

The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.  If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.  Providing deadlines without engaged people doesn't help. 

And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review. 







 		 	   		  



      
--0-226991051-1254150291=:30207--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 10:08:26 +0000
Message-ID: <4AC08252.4070407@deployingradius.com>
Date: Mon, 28 Sep 2009 11:30:58 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'Bernard Aboba' , radiusext@ops.ietf.org
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
>>   You haven't pointed out which portions of the design guidelines
>> document violate that section.  You have had multiple opportunities to
>> do so.
> 
> See attachment.

  I don't count "virtually all of the document is wrong" as a useful
comment.  It doesn't propose anything that can be done to the document
to correct the alleged flaws.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 08:48:54 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'Bernard Aboba'" , 
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 15:47:08 +0700
Message-ID: <002201ca4018$4cce9440$e66bbcc0$@net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01CA4052.F92D6C40"
Thread-Index: AcpADrOTp/TicD3oRs++sbmBV1NyhwACP66w
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01CA4052.F92D6C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto:aland@deployingradius.com] writes:
> > Speaking of which, perhaps you would like to address section 6 of RFC
> 2119.
> 
>   You haven't pointed out which portions of the design guidelines
> document violate that section.  You have had multiple opportunities to
> do so.

See attachment.

> 
>   I don't see why I should address non-existent issues.
> 
>   Alan DeKok.

------=_NextPart_000_0023_01CA4052.F92D6C40
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

Received: from psg.com ([147.28.0.62])
	by IMTA26.emeryville.ca.mail.comcast.net with comcast
	id m1bc1c00u1LFiyT0S1bdCG; Mon, 28 Sep 2009 01:35:39 +0000
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from )
	id 1Ms53t-000LGI-Mq
	for radiusext-data0@psg.com; Mon, 28 Sep 2009 01:29:57 +0000
Received: from [76.96.59.243] (helo=QMTA13.westchester.pa.mail.comcast.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from )
	id 1Ms53i-000LFH-5r
	for radiusext@ops.ietf.org; Mon, 28 Sep 2009 01:29:55 +0000
Received: from imta26.emeryville.ca.mail.comcast.net (LHLO
 IMTA26.emeryville.ca.mail.comcast.net) (76.96.30.79) by
 sz0087.ev.mail.comcast.net with LMTP; Mon, 28 Sep 2009 01:35:39 +0000 (UTC)
Received: from gwzPC ([124.120.229.49])
	by OMTA20.westchester.pa.mail.comcast.net with comcast
	id m1Yv1c00L14bZwC3g1Z2EH; Mon, 28 Sep 2009 01:33:52 +0000
Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71])
	by QMTA13.westchester.pa.mail.comcast.net with comcast
	id lzn81c0081YDfWL5D1VlZz; Mon, 28 Sep 2009 01:29:45 +0000
Return-Path: 
From: "Glen Zorn" 
Sender: 
To: "'Bernard Aboba'" 
Cc: ,
	,
	,
	,
	,
	,
	
References:   
In-Reply-To: 
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 08:28:14 +0700
Message-ID: <00e701ca3fdb$15030e70$3f092b50$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01CA4052.F92D1E20"
X-Mailer: Microsoft Office Outlook 12.0
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,	RDNS_NONE autolearn=no version=3.2.5
Thread-Index: Aco/i0q3aXmPsMIKQKmytfpn73cgjQAS6KIA
Content-Language: en-us
X-Authority-Analysis: v=1.0 c=1 a=RTLZkadmLlh5NdvcQZkdJA==:17 a=69EAbJreAAAA:8 a=5qO9ka6rXXjxde1-UtQA:9 a=gI16K7ckjlo9FLWOiLeawOZkztUA:4 a=EfJqPEOeqlMA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Ds7fev4g2VRAc5b2T6kA:9 a=R3SAO3oMq3M80DiQXUEA:7 a=3NTFqp_U0Y2X103m7LfJIx-CgecA:4
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on psg.com
X-Message-Flag: Follow up

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01CA4052.F92D1E20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com]  writes:

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

 

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

 

 

[BA] Are there specific uses of normative language in the document that you
believe are inappropriate?   

With the caveat that it's been some time since I read the draft, based upon
my last review I'd have to say virtually all the uses of RFC 2119
requirements language in the document are problematic.  I plan to go through
the note in depth again this week.  There is a lot of nonsense in it which I
had mistakenly considered innocuous blather, easily ignored (they are
"guidelines", after all).  However,  at some point during the final
discussions before the publication of RFC 5580 I realized that the document,
far from being a set of harmless suggestions on style, was in fact a club to
be used by pompous asses to keep people from getting real work done.  If you
recall, my major arguments against the attributes defined in 5580 were based
upon non-compliance w/the Design Guidelines document (yes, that would make
me one of those pompous asses & I would like to take this opportunity to
apologize to the authors of RFC 5580, the geopriv WG and the IESG for my
misguided behavior).  In fact, though, there was nothing technically wrong
with the geopriv attributes: they would have worked just fine, thank you.
Their only sin was deviation from a set of rules based upon a highly suspect
historical characterization of RADIUS development and a simplistic (if not
downright primitive processing model).  At any rate, removing the RFC 2119
language from the draft would go a long way toward making the document truly
harmless.


------=_NextPart_000_001E_01CA4052.F92D1E20
Content-Type: text/html;
	boundary="----=_NextPart_000_00E8_01CA4015.C161E670";
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

































Bernard Aboba [mailto:bernard_aboba@hotmail.com] =
 writes:



WRT this document,
section 6 of RFC 2119 (sorry about the typo above) seems =
relevant:=




6.
Guidance in the use of these Imperatives



 =




  
Imperatives of the type defined in this memo must be used with =
care=




  
and sparingly.  In particular, they MUST only be used where it =
is=




  
actually required for interoperation or to limit behavior which =
has=




  
potential for causing harm (e.g., limiting retransmisssions)  =
For=




  
example, they must not be used to try to impose a particular =
method=




  
on implementors where the method is not required for=




  
interoperability.=




 



 



[BA]
Are there specific uses of normative language in the document that you =
believe
are inappropriate?   



With the caveat that it’s been some time since I =
read the
draft, based upon my last review I’d have to say virtually all the =
uses
of RFC 2119 requirements language in the document are problematic.  =
I plan
to go through the note in depth again this week.  There is a lot of
nonsense in it which I had mistakenly considered innocuous blather, =
easily
ignored (they are “guidelines”, after all).  However, =
 at
some point during the final discussions before the publication of RFC =
5580 I realized
that the document, far from being a set of harmless suggestions on =
style, was in
fact a club to be used by pompous asses to keep people from getting real =
work
done.  If you recall, my major arguments against the attributes =
defined in
5580 were based upon non-compliance w/the Design Guidelines document =
(yes, that
would make me one of those pompous asses & I would like to take this
opportunity to apologize to the authors of RFC 5580, the geopriv WG and =
the
IESG for my misguided behavior).  In fact, though, there was =
nothing
technically wrong with the geopriv attributes: they would have worked =
just
fine, thank you.  Their only sin was deviation from a set of rules =
based
upon a highly suspect historical characterization of RADIUS development =
and a
simplistic (if not downright primitive processing model).  At any =
rate,
removing the RFC 2119 language from the draft would go a long way toward =
making
the document truly harmless.
























------=_NextPart_000_001E_01CA4052.F92D1E20--

------=_NextPart_000_0023_01CA4052.F92D6C40--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 07:39:18 +0000
Message-ID: <4AC067FE.4030808@deployingradius.com>
Date: Mon, 28 Sep 2009 09:38:38 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'Bernard Aboba' , radiusext@ops.ietf.org
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
> Speaking of which, perhaps you would like to address section 6 of RFC 2119.

  You haven't pointed out which portions of the design guidelines
document violate that section.  You have had multiple opportunities to
do so.

  I don't see why I should address non-existent issues.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 07:21:31 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" , "'MILES DAVID'" 
Cc: "'Bernard Aboba'" , , , "'David B. Nelson'" , , "'Mark Townsley'" 
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:20:00 +0700
Message-ID: <001d01ca400c$2816ab80$78440280$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcpABmtwBdPN6j9zSAi5ICst7Be+rAAA+1QQ
Content-Language: en-us

Alan DeKok [aland@destroyingradius.com] writes:

> MILES DAVID wrote:
> >> Uplink-IPv6-Address instead of IPv6-Address
> > 	I know the supporting text says "is assigned to the uplink of
> > the user equipment" but uplink may be confusing (the uplink of what)
> -
> > Peer/Subscriber/Host-IPv6-Address perhaps?
> 
>   Just something more specific than "IPv6-Address".  There are a lot of
> possible uses for IPv6 addresses.  Having an attribute named just
> "IPv6-Address" will be confusing.

Or useful; maybe they're the same thing?

> 
> >
> >> IPv6-Route-Option-Preference
> > 	Per your review - I too agree that a signed integer is somewhat
> > confusing however this is a direct copy of a DHCP option 

I think it's actually from a Router Advertisement message, but no matter.

> from RFC 4191:
> 
>   OK.  Is this attribute intended to transport that DHCP option, or to
> mirror the functionality?
> 
>   There are no signed integers in RADIUS, and 16 bit integers are not
> recommended.  I would suggest instead that the RADIUS definition of the
> attribute be "2 octets", and that the definition refers to the
> appropriate section of RFC 4191.

Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
single octet.

> 
>   i.e. leave the practical use of the attribute unchanged.  But change
> the definition to refer to another specification, rather than
> duplicating the definition here.

That's a fine idea.

...

> >> Prefix-Lifetime-Service-Type
> > Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
> > integer. IMO this is not a big change one way or another - I have no
> > objection to changing this.

Again, a single octet should suffice, no?

...


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 07:05:13 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'Bernard Aboba'" , 
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:03:40 +0700
Message-ID: <001c01ca4009$d90f6ab0$8b2e4010$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcpAAcD2Wq9KlphZSM+pbgyzl7ZAxAABQ/bA
Content-Language: en-us

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
> > Somebody should note (might as well be me) that since the 1) the
> > document is not a protocol specification & 2) the intended status is
> > BCP, the use of RFC 2118 keywords is inappropriate to begin with.
> 
>   Here's a list of RFCs that:
> 
>     (a) are Status: BCP
>     (b) have the word "guidelines" in their title
>     (c) use RFC 2119 keywords
>     (d) are relatively recent
> 
> 	http://tools.ietf.org/html/rfc3470
> 
> 	http://tools.ietf.org/html/rfc3552
> 
> 	http://tools.ietf.org/html/rfc4107
> 
> 	http://tools.ietf.org/html/rfc4181
> 
> 	http://tools.ietf.org/html/rfc4395
> 
> 	http://tools.ietf.org/html/rfc5226
> 
> 	http://tools.ietf.org/html/rfc5405
> 
> 	http://tools.ietf.org/html/rfc5625
> 
>   That's 8 documents in about 5 minutes of work.  I think your claim
> has
> been proven false.  The design guidelines document is following the
> current practice of the IETF.  The only way to disprove this is
> outright
> denial.

Speaking of which, perhaps you would like to address section 6 of RFC 2119.
Glad you've decided to do a little research once in a while, BTW ;-): you
have provided a treasure trove of material for RFC Errata.

> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 06:36:52 +0000
Message-ID: <4AC05969.7060400@deployingradius.com>
Date: Mon, 28 Sep 2009 08:36:25 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: MILES DAVID 
CC: Bernard Aboba , sarikaya@ieee.org,  radiusext@ops.ietf.org, "David B. Nelson" ,  roberta.maglione@telecomitalia.it, Mark Townsley 
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

MILES DAVID wrote:
>> Uplink-IPv6-Address instead of IPv6-Address
> 	I know the supporting text says "is assigned to the uplink of
> the user equipment" but uplink may be confusing (the uplink of what) -
> Peer/Subscriber/Host-IPv6-Address perhaps?

  Just something more specific than "IPv6-Address".  There are a lot of
possible uses for IPv6 addresses.  Having an attribute named just
"IPv6-Address" will be confusing.

> 
>> IPv6-Route-Option-Preference
> 	Per your review - I too agree that a signed integer is somewhat
> confusing however this is a direct copy of a DHCP option from RFC 4191:

  OK.  Is this attribute intended to transport that DHCP option, or to
mirror the functionality?

  There are no signed integers in RADIUS, and 16 bit integers are not
recommended.  I would suggest instead that the RADIUS definition of the
attribute be "2 octets", and that the definition refers to the
appropriate section of RFC 4191.

  i.e. leave the practical use of the attribute unchanged.  But change
the definition to refer to another specification, rather than
duplicating the definition here.

>> IPv6-Route-Option-Lifetime:
>> Auth-IPv6-Prefix-Valid-Lifetime:
...
> Again these 32-bit values are straight out of RFC 4191 and there is a
> requirement to support a value of infinity (0xffffffff). I think you
> could get away with a 24-bit value and a special recognition of
> infinity, but it is not desirable. If we adopt a fixed tag definition
> per Bernard's suggestion, do we still have a problem?

  It's still a new data type, but I think the alternatives would be worse.

>> Prefix-Lifetime-Service-Type
> Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
> integer. IMO this is not a big change one way or another - I have no
> objection to changing this.

  OK.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 06:22:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 14:20:54 +0800
Message-ID: <986DCE2E44129444B6435ABE8C9E424D02DC138C@SGSINSMBS02.ad4.ad.alcatel.com>
Thread-Topic: IPv6 Address Option
Thread-Index: Aco//pJhCvlaUqf8TuayIKdQqUPnJQAApbhA
From: "MILES DAVID" 
To: "Alan DeKok" 
Cc: "Bernard Aboba" , , , "David B. Nelson" , , "Mark Townsley" 

Sorry Alan,

I missed that one.

My comments on each point:

>Uplink-IPv6-Address instead of IPv6-Address
	I know the supporting text says "is assigned to the uplink of
the user equipment" but uplink may be confusing (the uplink of what) -
Peer/Subscriber/Host-IPv6-Address perhaps?


>IPv6-Route-Option-Preference
	Per your review - I too agree that a signed integer is somewhat
confusing however this is a direct copy of a DHCP option from RFC 4191:
Prf (Default Router Preference)
            2-bit signed integer.  Indicates whether to prefer this
            router over other default routers.  If the Router Lifetime
            is zero, the preference value MUST be set to (00) by the
            sender and MUST be ignored by the receiver.  If the Reserved
            (10) value is received, the receiver MUST treat the value as
            if it were (00).

  Preference values are encoded as a two-bit signed integer, as
   follows:

      01      High
      00      Medium (default)
      11      Low
      10      Reserved - MUST NOT be sent



> IPv6-Route-Option-Lifetime:
> Auth-IPv6-Prefix-Valid-Lifetime:
>=20
>   Defining a tag field *and* a 32-bit integer means that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section 3.1 for the historical definition.
>=20
>   It would seem to be OK to have a 24-bit lifetime.  That would allow
> everyone to use this attribute by simply updating their dictionaries,
> rather than writing new code to handle a new format.

Again these 32-bit values are straight out of RFC 4191 and there is a
requirement to support a value of infinity (0xffffffff). I think you
could get away with a 24-bit value and a special recognition of
infinity, but it is not desirable. If we adopt a fixed tag definition
per Bernard's suggestion, do we still have a problem?

=20
> Prefix-Lifetime-Service-Type
Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
integer. IMO this is not a big change one way or another - I have no
objection to changing this.



Cheers,

-David


-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.com]=20
Sent: Monday, 28 September 2009 3:13 PM
To: MILES DAVID
Cc: Bernard Aboba; sarikaya@ieee.org; radiusext@ops.ietf.org; David B.
Nelson; roberta.maglione@telecomitalia.it; Mark Townsley
Subject: Re: IPv6 Address Option

MILES DAVID wrote:
> I see no other outstanding issues in the minutes or on the RADEXT
issues
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 06:06:35 +0000
Message-ID: <4AC05245.4010406@deployingradius.com>
Date: Mon, 28 Sep 2009 08:05:57 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'Bernard Aboba' , radiusext@ops.ietf.org
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
> Somebody should note (might as well be me) that since the 1) the
> document is not a protocol specification & 2) the intended status is
> BCP, the use of RFC 2118 keywords is inappropriate to begin with.

  Here's a list of RFCs that:

    (a) are Status: BCP
    (b) have the word "guidelines" in their title
    (c) use RFC 2119 keywords
    (d) are relatively recent

	http://tools.ietf.org/html/rfc3470

	http://tools.ietf.org/html/rfc3552

	http://tools.ietf.org/html/rfc4107

	http://tools.ietf.org/html/rfc4181

	http://tools.ietf.org/html/rfc4395

	http://tools.ietf.org/html/rfc5226

	http://tools.ietf.org/html/rfc5405

	http://tools.ietf.org/html/rfc5625

  That's 8 documents in about 5 minutes of work.  I think your claim has
been proven false.  The design guidelines document is following the
current practice of the IETF.  The only way to disprove this is outright
denial.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 05:43:43 +0000
Message-ID: <4AC04CC8.2030609@deployingradius.com>
Date: Mon, 28 Sep 2009 07:42:32 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: MILES DAVID 
CC: Bernard Aboba , sarikaya@ieee.org,  radiusext@ops.ietf.org, "David B. Nelson" ,  roberta.maglione@telecomitalia.it, Mark Townsley 
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

MILES DAVID wrote:
> I see no other outstanding issues in the minutes or on the RADEXT issues
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 03:31:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 11:30:40 +0800
Message-ID: <986DCE2E44129444B6435ABE8C9E424D02DC138B@SGSINSMBS02.ad4.ad.alcatel.com>
Thread-Topic: IPv6 Address Option
Thread-Index: Aco/r6lnlH3obrcVTzmcMbi44RLwowAN1UIw
From: "MILES DAVID" 
To: "Bernard Aboba" , , , "David B. Nelson" 
Cc: , "Mark Townsley" 

Hi Bernard,

My email was simply an opportunity to prompt continued discussions from
Stockholm (things had been somewhat quiet).

To the question of tagged AVP,  your suggested rewording of
radext-design-07 :

For these reasons, the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types,
   it is RECOMMENDED that:
     =20
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present;=20

        * The design make no assumption about the content of the
          data within tagged attributes." =20

to require new AVP which implement tagged values must treat them as a
fixed/mandatory is to me the best approach _if_ it is decided that these
AVP should not fall under the guidelines of radext-extended-attributes.
My opinion is that radext-design-07 should be updated to include the
proposed text above. After that modification I believe the current text
in ipv6-access-01 around tags:

The Tag field is mandatory.  The Tag
      field values are greater than 0x00.

 Is sufficient to allow the adoption of this draft.

I see no other outstanding issues in the minutes or on the RADEXT issues
list for draft-lourdelet-radext-ipv6-access. Should I post your proposed
text as an issue to the list for tracking?


Cheers,

-David





--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 28 Sep 2009 01:30:37 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
Cc: , , , , , , 
Subject: RE: IPv6 Address Option
Date: Mon, 28 Sep 2009 08:28:14 +0700
Message-ID: <00e701ca3fdb$15030e70$3f092b50$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E8_01CA4015.C161E670"
Thread-Index: Aco/i0q3aXmPsMIKQKmytfpn73cgjQAS6KIA
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_00E8_01CA4015.C161E670
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com]  writes:

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

 

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

 

 

[BA] Are there specific uses of normative language in the document that you
believe are inappropriate?   

With the caveat that it's been some time since I read the draft, based upon
my last review I'd have to say virtually all the uses of RFC 2119
requirements language in the document are problematic.  I plan to go through
the note in depth again this week.  There is a lot of nonsense in it which I
had mistakenly considered innocuous blather, easily ignored (they are
"guidelines", after all).  However,  at some point during the final
discussions before the publication of RFC 5580 I realized that the document,
far from being a set of harmless suggestions on style, was in fact a club to
be used by pompous asses to keep people from getting real work done.  If you
recall, my major arguments against the attributes defined in 5580 were based
upon non-compliance w/the Design Guidelines document (yes, that would make
me one of those pompous asses & I would like to take this opportunity to
apologize to the authors of RFC 5580, the geopriv WG and the IESG for my
misguided behavior).  In fact, though, there was nothing technically wrong
with the geopriv attributes: they would have worked just fine, thank you.
Their only sin was deviation from a set of rules based upon a highly suspect
historical characterization of RADIUS development and a simplistic (if not
downright primitive processing model).  At any rate, removing the RFC 2119
language from the draft would go a long way toward making the document truly
harmless.


------=_NextPart_000_00E8_01CA4015.C161E670
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable































Bernard Aboba [mailto:bernard_aboba@hotmail.com] =
 writes:



WRT this document,
section 6 of RFC 2119 (sorry about the typo above) seems =
relevant:=




6.
Guidance in the use of these Imperatives



 =




  
Imperatives of the type defined in this memo must be used with =
care=




  
and sparingly.  In particular, they MUST only be used where it =
is=




  
actually required for interoperation or to limit behavior which =
has=




  
potential for causing harm (e.g., limiting retransmisssions)  =
For=




  
example, they must not be used to try to impose a particular =
method=




  
on implementors where the method is not required for=




  
interoperability.=




 



 



[BA]
Are there specific uses of normative language in the document that you =
believe
are inappropriate?   



With the caveat that it’s been some time since I =
read the
draft, based upon my last review I’d have to say virtually all the =
uses
of RFC 2119 requirements language in the document are problematic.  =
I plan
to go through the note in depth again this week.  There is a lot of
nonsense in it which I had mistakenly considered innocuous blather, =
easily
ignored (they are “guidelines”, after all).  However, =
 at
some point during the final discussions before the publication of RFC =
5580 I realized
that the document, far from being a set of harmless suggestions on =
style, was in
fact a club to be used by pompous asses to keep people from getting real =
work
done.  If you recall, my major arguments against the attributes =
defined in
5580 were based upon non-compliance w/the Design Guidelines document =
(yes, that
would make me one of those pompous asses & I would like to take this
opportunity to apologize to the authors of RFC 5580, the geopriv WG and =
the
IESG for my misguided behavior).  In fact, though, there was =
nothing
technically wrong with the geopriv attributes: they would have worked =
just
fine, thank you.  Their only sin was deviation from a set of rules =
based
upon a highly suspect historical characterization of RADIUS development =
and a
simplistic (if not downright primitive processing model).  At any =
rate,
removing the RFC 2119 language from the draft would go a long way toward =
making
the document truly harmless.
























------=_NextPart_000_00E8_01CA4015.C161E670--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 20:19:18 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_488386de-41e2-4753-a9c4-1561c6b41365_"
From: Bernard Aboba 
To: , , "radiusext@ops.ietf.org" , "David B. Nelson" 
CC: , Mark Townsley 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 13:18:16 -0700

 <481809.34957.qm@web111408.mail.gq1.yahoo.com>
MIME-Version: 1.0

--_488386de-41e2-4753-a9c4-1561c6b41365_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> No. Several people replied. They just supported the call without any comm=
ents=2C but they promised to comment.

In looking at the archive=2C these are the only people whose response indic=
ated support of the document:=20

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html

Aside from these individuals=2C who else has indicated support for the docu=
ment?  Please provide links to their emails.=20

>Well=2C we certainly would be happy to have David on board. However=2C I t=
hink the document already has an editor=2C actually two=2C i.e. Benoit and =
Glen.We could have three :).

The issue isn't how many editors the document has.  The issue is the pace a=
t which the document has evolved in response to feedback. =20

The IETF isn't a "work for hire" organization that exists to produce work i=
n response to liaison requests.  If an SDO such as Broadband Forum wants a =
document to move forward=2C then they need to supply the manpower to comple=
te the work=2C and enough people interested in it to provide appropriate re=
view.  Providing deadlines without engaged people doesn't help.=20

And if some aspect of the IETF process is acting as a bottleneck=2C the Des=
ign Guidelines document specifically provides a mechanism for the Broadband=
 Forum to complete the work on its own=2C engaging the IETF for review.=20







 		 	   		  =

--_488386de-41e2-4753-a9c4-1561c6b41365_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







>=3B No. Several people replied. They just supported the call without=
 any comments=2C but they promised to comment.

In looking at the arc=
hive=2C these are the only people whose response indicated support of the d=
ocument: 

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/20=
09/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/m=
sg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00=
354.html

Aside from these individuals=2C who else has indicated supp=
ort for the document? =3B Please provide links to their emails. 
>=3BWell=2C we certainly would be happy to have David on board. However=
=2C I think the document already has an editor=2C actually two=2C i.e. Beno=
it and Glen.We could have three :).

The issue isn't how many editors=
 the document has. =3B The issue is the pace at which the document has =
evolved in response to feedback. =3B 

The IETF isn't a "work for=
 hire" organization that exists to produce work in response to liaison requ=
ests. =3B If an SDO such as Broadband Forum wants a document to move fo=
rward=2C then they need to supply the manpower to complete the work=2C and =
enough people interested in it to provide appropriate review. =3B Provi=
ding deadlines without engaged people doesn't help. 

And if some asp=
ect of the IETF process is acting as a bottleneck=2C the Design Guidelines =
document specifically provides a mechanism for the Broadband Forum to compl=
ete the work on its own=2C engaging the IETF for review. 






 		 	   		  
=

--_488386de-41e2-4753-a9c4-1561c6b41365_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 16:43:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1254069793; bh=bCG7Ft38AZ5Jo3LI7npd0E8Nx66jLybPRZ9S28+BQk0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LrPVkX/Kk3bXrGGF2G0kVh9g2X9GjT5siLXuWP0G+J+/shXK2ZbhIeYcS4HW2yBWlHDFRQIqjxCzE5CrKbhCjeNSGypnt4SKq7g0/IuwgESWQ1Ijq/ooxz2QwhxUCo3J3qvulCcjYACCFktv8wCKIjZ7kkhYAsmbOVqbWe6wzDQ=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DswOxkZU6co4RIAU/kB0m4+l5htllaTKYKOW4ADeD8WMWbg9JBG590clcquZdL6P2Yc8nm6zwO0aJSBybPZ/e2mUf+OHcvBgl4oE3amB3KP8l3MYOfGj6p/oxrwBMa+QPK1o/tpfQITBz4skQIRt2+aONwujPrcJPo58zoIjues=;
Message-ID: <481809.34957.qm@web111408.mail.gq1.yahoo.com>
Date: Sun, 27 Sep 2009 09:43:13 -0700 (PDT)
From: Behcet Sarikaya 
Reply-To: Behcet Sarikaya 
Subject: Re: IPv6 Address Option
To: Bernard Aboba , david.miles@alcatel-lucent.com.au, "radiusext@ops.ietf.org" , "David B. Nelson" 
Cc: roberta.maglione@telecomitalia.it, Mark Townsley 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi Bernard,


>
>From: Bernard Aboba 
>To: david.miles@alcatel-lucent.com.au; "radiusext@ops.ietf.org" ; David B. Nelson 
>Cc: roberta.maglione@telecomitalia.it; Mark Townsley 
>Sent: Saturday, September 26, 2009 7:21:27 PM
>Subject: RE: IPv6 Address Option
>
> >
>> A few months back some of us expressed a desire to proceed with the
>> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
>> item. 
>
>On June 25, 2009 there was a WG call for interest in the document: 
>http://ops.ietf.org/lists/radiusext/2009/msg00273.html
>
>Only one person other than yourself and the authors replied to the call for interest. 
>

No. Several people replie. They just supported the call without any comments, but they promised to comment.

>In addition, the document has not been revised in response to WG comments. 
>
>> In the recent Broadband Forum meeting in Tokyo it was announced
>> that the BBF will seek to finalize their document on IPv6 for PPP
>> environments (to which I am co-editor). With the lack of some essential
>> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
>> a hard place.
>
>If there was interest from the Broadband Forum, why has noone bothered to
>respond to the call for interest or to revise the document? 
>
>> Delaying the IPv6 for PPP document much beyond November is not an option
>
>If that is the case, why are the concerned parties not doing more to move it forward? 
>
>> I am happy to work with the current authors to create a draft which can be fast tracked.
>
>If you're volunteering to act as editor, that would be great.  Next step would be to issue a 
>version of the document addressing outstanding comments.  We can then discuss the 
>document at the October 13 Virtual Interim meeting. 
>
>

Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

Regards,

Behcet



      

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 16:12:07 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_ab60308e-9082-46a5-8e1b-ccdf8704a708_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Agenda for Interim Meeting - Take Two
Date: Sun, 27 Sep 2009 09:11:40 -0700
MIME-Version: 1.0

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Strawman Agenda

8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Agenda Bash
   Document Status=20

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

Under Consideration for Adoption (30 minutes)

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

9:30 AM - 9:40 AM Requirements for IPv6 over PPP=2C David Miles (10 minutes=
)
http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access

9:40 AM - 9:50 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba =
(10 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan



 		 	   		  =

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Strawman Agenda

8:00 AM - 8:20 AM  Preliminaries
   Jabber s=
cribe
   Agenda Bash
   Document Status 

Documents completing =
IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines docu=
ment=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-r=
adext-design

Documents Completing WG Last Call (20 minutes)

8=
:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.=
org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server do=
cument=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-=
radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C A=
lan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-=
transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-ba=
sed Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/h=
tml/draft-ietf-radext-dynamic-discovery

Under Consideration for Adop=
tion (30 minutes)

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (=
10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls

9:=
30 AM - 9:40 AM Requirements for IPv6 over PPP=2C David Miles (10 minutes)<=
br>http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access

9:4=
0 AM - 9:50 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba (10=
 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan


=


 		 	   		  


 		 	   		  
=

--_ab60308e-9082-46a5-8e1b-ccdf8704a708_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 15:58:37 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_80404be2-30c3-4199-a317-19e38825fbf0_"
From: Bernard Aboba 
To: Glen Zorn 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 08:58:00 -0700

 <008901ca3f50$a322c960$e9685c20$@net>
MIME-Version: 1.0

--_80404be2-30c3-4199-a317-19e38825fbf0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




WRT this document=2C section 6 of RFC 2119 (sorry about the typo
above) seems relevant:

6. Guidance in the use of these Imperatives

=20

   Imperatives of the type defined in this
memo must be used with care

   and sparingly.  In particular=2C
they MUST only be used where it is

   actually required for interoperation or
to limit behavior which has

   potential for causing harm (e.g.=2C
limiting retransmisssions)  For

   example=2C they must not be used to try
to impose a particular method

   on implementors where the method is not
required for

   interoperability.

=20
[BA] Are there specific uses of normative language in the document that you=
 believe are inappropriate? =20







 		 	   		  =

--_80404be2-30c3-4199-a317-19e38825fbf0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








WRT this document=2C section 6 o=
f RFC 2119 (sorry about the typo
above) seems relevant:



6. Guidance in the use of these Imperatives



 =3B



 =3B =3B Imperatives of the type defined=
 in this
memo must be used with care



 =3B =3B and sparingly. =3B In parti=
cular=2C
they MUST only be used where it is



 =3B =3B actually required for interoper=
ation or
to limit behavior which has



 =3B =3B potential for causing harm (e.g=
.=2C
limiting retransmisssions) =3B For



 =3B =3B example=2C they must not be use=
d to try
to impose a particular method



 =3B =3B on implementors where the metho=
d is not
required for



 =3B =3B interoperability.



 =3B=


=

[BA] Are there specific uses of normative language in the document that=
 you believe are inappropriate?  =3B











 		 	   		  
=

--_80404be2-30c3-4199-a317-19e38825fbf0_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 15:47:24 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_289e488d-de66-4fff-bd63-021df62db0b7_"
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6
Date: Sun, 27 Sep 2009 08:46:39 -0700

 <4ABF2DA4.7080602@deployingradius.com>
MIME-Version: 1.0

--_289e488d-de66-4fff-bd63-021df62db0b7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Old text:
>=20
>    New attributes SHOULD NOT use this tagging method because of the
>    limitations described above.
>=20
> New text:
>=20
>    Where these limitations do not apply=2C new attributes MAY use this
>    tagging method=2C though it is NOT RECOMMENDED.  Where the above
>    limitations apply=2C this tagging method SHOULD NOT be used.

Here is the original text of Section 2.1.2:

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values=2C because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (assuming the tag is optional).

   Other limitations of the tagging mechanism are that when integer
   values are tagged=2C the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.
"

How about this?=20

"2.1.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the use of
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of using the same tag value.
   As stated in [RFC2868] Section 3.3:

      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F=2C it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F=2C it SHOULD be
      interpreted as the first byte of the following String field.

   This tagging mechanism has some drawbacks.  There are a limited
   number of unique tags (31).  The tags are not well suited for use
   with arbitrary binary data values=2C because it is not always possible
   to tell if the first byte after the Length is the tag or the first
   byte of the untagged value (e.g. where the first byte of the following
   String field falls in the range of 0x00 through 0x1F).=20

   Other limitations of the tagging mechanism are that when integer
   values are tagged=2C the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and managing RADIUS
   systems.

   For these reasons=2C the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types=2C
   it is RECOMMENDED that:
     =20
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present=3B=20

        * The design make no assumption about the content of the
          data within tagged attributes." =20




 		 	   		  =

--_289e488d-de66-4fff-bd63-021df62db0b7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B Old text:
>=3B 
>=3B    New attributes SHOULD NOT use this=
 tagging method because of the
>=3B    limitations described above.>=3B 
>=3B New text:
>=3B 
>=3B    Where these limitation=
s do not apply=2C new attributes MAY use this
>=3B    tagging method=
=2C though it is NOT RECOMMENDED.  Where the above
>=3B    limitations=
 apply=2C this tagging method SHOULD NOT be used.

Here is the origin=
al text of Section 2.1.2:

"
2.1.2.  Tagging Mechanism

   =
[RFC2868] defines an attribute grouping mechanism based on the use of
  =
 a one octet tag value.  Tunnel attributes that refer to the same
   tun=
nel are grouped together by virtue of using the same tag value.

   T=
his tagging mechanism has some drawbacks.  There are a limited
   number=
 of unique tags (31).  The tags are not well suited for use
   with arbi=
trary binary data values=2C because it is not always possible
   to tell=
 if the first byte after the Length is the tag or the first
   byte of t=
he untagged value (assuming the tag is optional).

   Other limitatio=
ns of the tagging mechanism are that when integer
   values are tagged=
=2C the value portion is reduced to three bytes
   meaning only 24-bit n=
umbers can be represented.  The tagging
   mechanism does not offer an a=
bility to create nested groups of
   attributes.  Some RADIUS implementa=
tions treat tagged attributes as
   having additional data types tagged-=
string and tagged-integer.  These
   types increase the complexity of im=
plementing and managing RADIUS
   systems.

   New attributes SHOU=
LD NOT use this tagging method because of the
   limitations described a=
bove.
"

How about this? 

"2.1.2.  Tagging Mecha=
nism

   [RFC2868] defines an attribute grouping mechanism based on t=
he use of
   a one octet tag value.  Tunnel attributes that refer to the=
 same
   tunnel are grouped together by virtue of using the same tag val=
ue.
   As stated in [RFC2868] Section 3.3:

      The Tag field is=
 one octet in length and is intended to provide a
      means of groupin=
g attributes in the same packet which refer to the
      same tunnel.  I=
f the value of the Tag field is greater than 0x00
      and less than or=
 equal to 0x1F=2C it SHOULD be interpreted as
      indicating which tun=
nel (of several alternatives) this attribute
      pertains.  If the Tag=
 field is greater than 0x1F=2C it SHOULD be
      interpreted as the fir=
st byte of the following String field.

   This tagging mechanism has=
 some drawbacks.  There are a limited
   number of unique tags (31).  Th=
e tags are not well suited for use
   with arbitrary binary data values=
=2C because it is not always possible
   to tell if the first byte after=
 the Length is the tag or the first
   byte of the untagged value (e.g. =
where the first byte of the following
   String field falls in the range=
 of 0x00 through 0x1F). 

   Other limitations of the tagging mechani=
sm are that when integer
   values are tagged=2C the value portion is re=
duced to three bytes
   meaning only 24-bit numbers can be represented. =
 The tagging
   mechanism does not offer an ability to create nested gro=
ups of
   attributes.  Some RADIUS implementations treat tagged attribut=
es as
   having additional data types tagged-string and tagged-integer. =
 These
   types increase the complexity of implementing and managing RAD=
IUS
   systems.

   For these reasons=2C the tagging scheme descri=
bed in RFC 2868 is
   not suitable for use as a generic grouping mechani=
sm.  Where
   a tagging scheme is required for use with arbitrary data t=
ypes=2C
   it is RECOMMENDED that:
      
        * A fixed taggin=
g field be used so as to remove potential
          interoperability iss=
ues associated with determining whether
          an optional tag is pre=
sent=3B 

        * The design make no assumption about the content o=
f the
          data within tagged attributes."  




 		 	   		  
=

--_289e488d-de66-4fff-bd63-021df62db0b7_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 12:58:23 +0000
From: "Dave Nelson" 
To: 
Subject: RE: IPv6
Date: Sun, 27 Sep 2009 08:57:24 -0400
Message-ID: <5E49445CEA8F4CE39B1F29FB9084D344@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aco/SQYKSHf8WplWSkuL3QuQe5OoFwAKNIUg

Bernard Aboba writes...

> Either the Design Guidelines advice is appropriate or it isn't. 
>
> If it isn't right, then we should fix it, because eventually
> it will become an RFC and "racing against" it won't work any
> more.  If it is right, then we should try to adhere to the
> guidelines -- that's what they are there for.

+1



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 09:18:13 +0000
Message-ID: <4ABF2DA4.7080602@deployingradius.com>
Date: Sun, 27 Sep 2009 11:17:24 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: IPv6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Alan DeKok said:
> 
> "I suggest racing against the design guidelines document. After all,
> it's only a draft. If the IPv6 document can get published first, then
> the design guidelines matter a lot less."
> 
> [BA] Either the Design Guidelines advice is appropriate or it isn't.

  The comment was an attempt at humor, to counter the vitriol directed
at the design guidelines document.

> In this particular case, my take is that the Design Guidelines document
> is saying "don't do precisely what RFC 2868 did".  That is quite
> sensible.  However, it might also be helpful to say "Here are the
> problems that were caused by RFC 2868's scheme, and here is some advice
> to avoid those issues".  That way, until we finish the Extended
> Attributes document, we'll have some way to address these kind of
> situations.

  Update 2.1.1 Tag Mechanism:

Old text:

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.

New text:

   Where these limitations do not apply, new attributes MAY use this
   tagging method, though it is NOT RECOMMENDED.  Where the above
   limitations apply, this tagging method SHOULD NOT be used.


  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 08:59:27 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
Cc: 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 15:57:45 +0700
Message-ID: <008901ca3f50$a322c960$e9685c20$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01CA3F8B.4F81A160"
Thread-Index: Aco/Ru2ZQkifLn25Qk2hPLb844lVIQACSyng
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01CA3F8B.4F81A160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.


[BA] Where does it say that BCPs can't contain normative keywords?  Lots of
other BCPs seem to use them. 

WRT this document, section 6 of RFC 2119 (sorry about the typo above) seems
relevant:

6. Guidance in the use of these Imperatives

 

   Imperatives of the type defined in this memo must be used with care

   and sparingly.  In particular, they MUST only be used where it is

   actually required for interoperation or to limit behavior which has

   potential for causing harm (e.g., limiting retransmisssions)  For

   example, they must not be used to try to impose a particular method

   on implementors where the method is not required for

   interoperability.

 


------=_NextPart_000_008A_01CA3F8B.4F81A160
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

























Bernard Aboba
[mailto:bernard_aboba@hotmail.com] writes:

Somebody should note (might as well be me) that since the =
1) the
document is not a protocol specification & 2) the intended status is =
BCP,
the use of RFC 2118 keywords is inappropriate to begin with.=






[BA] Where does it say that BCPs can't contain normative keywords?  =
Lots
of other BCPs seem to use them. 



WRT this document, section 6 of RFC 2119 (sorry about the =
typo
above) seems relevant:



6. Guidance in the use of these =
Imperatives



 



   Imperatives of the type defined =
in this
memo must be used with care



   and sparingly.  In =
particular,
they MUST only be used where it is



   actually required for =
interoperation or
to limit behavior which has



   potential for causing harm =
(e.g.,
limiting retransmisssions)  For



   example, they must not be used =
to try
to impose a particular method



   on implementors where the method =
is not
required for



   =
interoperability.



 


















------=_NextPart_000_008A_01CA3F8B.4F81A160--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 08:02:18 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Re:  IPv6
Date: Sun, 27 Sep 2009 01:01:45 -0700
MIME-Version: 1.0

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Alan DeKok said:

"I suggest racing against the design guidelines document.  After all=2C
it's only a draft.  If the IPv6 document can get published first=2C then
the design guidelines matter a lot less."

[BA] Either the Design Guidelines advice is appropriate or it isn't.=20

If it isn't right=2C then we should fix it=2C because eventually it will be=
come an RFC and "racing against" it won't work any more.=20
If it is right=2C then we should try to adhere to the guidelines -- that's =
what they are there for.=20

In this particular case=2C my take is that the Design Guidelines document i=
s saying "don't do precisely what RFC 2868 did".  That is quite sensible.  =
However=2C it might also be helpful to say "Here are the problems that were=
 caused by RFC 2868's scheme=2C and here is some advice to avoid those issu=
es".  That way=2C until we finish the Extended Attributes document=2C we'll=
 have some way to address these kind of situations.=20





 		 	   		  =

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Alan DeKok said:

"I suggest racing against the design guidelines doc=
ument.  After all=2C
it's only a draft.  If the IPv6 document can get pu=
blished first=2C then
the design guidelines matter a lot less."

[=
BA] Either the Design Guidelines advice is appropriate or it isn't. 
If it isn't right=2C then we should fix it=2C because eventually it will b=
ecome an RFC and "racing against" it won't work any more. 
If it is righ=
t=2C then we should try to adhere to the guidelines -- that's what they are=
 there for. 

In this particular case=2C my take is that the Design G=
uidelines document is saying "don't do precisely what RFC 2868 did". =
=3B That is quite sensible. =3B However=2C it might also be helpful to =
say "Here are the problems that were caused by RFC 2868's scheme=2C and her=
e is some advice to avoid those issues". =3B That way=2C until we finis=
h the Extended Attributes document=2C we'll have some way to address these =
kind of situations. 





 		 	   		  
=

--_0df20e7a-0beb-45ef-9fdb-ebf6ad357778_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 07:49:03 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_2a5ac828-0a61-4a61-abdb-6d211e67d088_"
From: Bernard Aboba 
To: Glen Zorn 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 00:48:38 -0700

 <006401ca3f45$408ff530$c1afdf90$@net>
MIME-Version: 1.0

--_2a5ac828-0a61-4a61-abdb-6d211e67d088_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Somebody should note (might
as well be me) that since the 1) the document is not a protocol specificati=
on
& 2) the intended status is BCP=2C the use of RFC 2118 keywords is inapprop=
riate
to begin with.



[BA] Where does it say that BCPs can't contain normative keywords?  Lots of=
 other BCPs seem to use them.=20










=20
 =20

=20


=20



 		 	   		  =

--_2a5ac828-0a61-4a61-abdb-6d211e67d088_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












Somebody should note (might
as well be me) that since the 1) the document is not a protocol specificati=
on
&=3B 2) the intended status is BCP=2C the use of RFC 2118 keywords is in=
appropriate
to begin with.





[BA] Where does it say that BCPs can't contain normative keywords? =3B =
Lots of other BCPs seem to use them. 












 

  

 





 =3B






 		 	   		  
=

--_2a5ac828-0a61-4a61-abdb-6d211e67d088_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 07:47:15 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_84ad55d2-3394-4fe9-b938-55e63f669c2a_"
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 00:46:36 -0700

 <4ABF10D1.4050807@deployingradius.com>
MIME-Version: 1.0

--_84ad55d2-3394-4fe9-b938-55e63f669c2a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   The draft-lourdelet document defines a new data type.  8-bit tag=2C
> followed by 32-bit integer.  While this is arguably better than the RFC
> 2868 form=2C it still is a new data type.  And the document discourages
> new data types.

OK.  So the issue is not the use of RFC 2868 tags.=20

>   Maybe the document needs to say:
>=20
>    In order to meet these objectives=2C this document needs to cover not
>    only the science of attribute design=2C but also the art.  As a result=
=2C
>    in addition to covering the most frequently encountered issues=2C this
>    document attempts to provide some of the considerations motivating
>    the guidelines.  Reviewers are expected to weigh the cost and
>    benefits of following or ignoring the guidelines=2C as nearly all
>    suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
>    intent is for the guidelines to help authors create better documents.
>    This intent means that reviewers can choose to ignore some of the
>    recommendations herein.  When this is done=2C their review MUST be
>    accompanied by an explanation as to why the guidelines were not
>    followed=2C and why following the guidelines would have resulted in
>    a worse architecture.

Personally=2C I don't think this text is necessary=3B RFC 2119 defines the
meaning of SHOULD.=20

> >  Perhaps the Design Guidelilnes document should be more
> > clear about exactly what the flaws were in the RFC 2868 scheme that the
> > SHOULD NOT applies to.=20
>=20
>   Or=2C it could say that the tagging mechanism MAY be used when none of
> the above limitations apply.

Or=2C it might describe how a single octet tagging scheme might avoid the
problems of RFC 2868.=20
 		 	   		  =

--_84ad55d2-3394-4fe9-b938-55e63f669c2a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B   The draft-lourdelet document defines a new data type.  8-bit tag=
=2C
>=3B followed by 32-bit integer.  While this is arguably better th=
an the RFC
>=3B 2868 form=2C it still is a new data type.  And the doc=
ument discourages
>=3B new data types.

OK. =3B So the issue=
 is not the use of RFC 2868 tags. 

>=3B   Maybe the document needs=
 to say:
>=3B 
>=3B    In order to meet these objectives=2C this =
document needs to cover not
>=3B    only the science of attribute desi=
gn=2C but also the art.  As a result=2C
>=3B    in addition to coverin=
g the most frequently encountered issues=2C this
>=3B    document atte=
mpts to provide some of the considerations motivating
>=3B    the guid=
elines.  Reviewers are expected to weigh the cost and
>=3B    benefits=
 of following or ignoring the guidelines=2C as nearly all
>=3B    sugg=
estions here are of the form "SHOULD" or "SHOULD NOT".  The
>=3B    in=
tent is for the guidelines to help authors create better documents.
>=
=3B    This intent means that reviewers can choose to ignore some of the>=3B    recommendations herein.  When this is done=2C their review MUST =
be
>=3B    accompanied by an explanation as to why the guidelines were=
 not
>=3B    followed=2C and why following the guidelines would have r=
esulted in
>=3B    a worse architecture.

Personally=2C I don't =
think this text is necessary=3B RFC 2119 defines the
meaning of SHOULD. =


>=3B >=3B  Perhaps the Design Guidelilnes document should be mo=
re
>=3B >=3B clear about exactly what the flaws were in the RFC 2868=
 scheme that the
>=3B >=3B SHOULD NOT applies to. 
>=3B 
>=
=3B   Or=2C it could say that the tagging mechanism MAY be used when none o=
f
>=3B the above limitations apply.

Or=2C it might describe how=
 a single octet tagging scheme might avoid the
problems of RFC 2868.  		 	   		  
=

--_84ad55d2-3394-4fe9-b938-55e63f669c2a_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 07:37:45 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
Cc: 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 14:36:16 +0700
Message-ID: <006401ca3f45$408ff530$c1afdf90$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01CA3F7F.ECEECD30"
Thread-Index: Aco/PdailSukUmU2QziPXjtoXbjpGQABrBXg
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01CA3F7F.ECEECD30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba  
[mailto://bernard_aboba@hotmail.com] writes:

 

>"New attributes SHOULD NOT use this tagging method...". Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that
described in RFC 2868.  So does the Design Guidelines advice even apply
here?  Perhaps the Design Guidelilnes document should be more clear about
exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT
applies to.  



Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.








	

 


------=_NextPart_000_0065_01CA3F7F.ECEECD30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Bernard Aboba [mailto://bernard_aboba@hotmail.com] =
writes:



 






>"New attributes SHOULD NOT =
use
this tagging method...". Which is it?



The tagging scheme in draft-lourdelet does not have the same flaws as =
that
described in RFC 2868.  So does the Design Guidelines advice even =
apply
here?  Perhaps the Design Guidelilnes document should be more clear =
about
exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT =
applies
to.  







Somebody should =
note (might
as well be me) that since the 1) the document is not a protocol =
specification
& 2) the intended status is BCP, the use of RFC 2118 keywords is =
inappropriate
to begin with.


















 

  
 





 












------=_NextPart_000_0065_01CA3F7F.ECEECD30--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 07:14:59 +0000
Message-ID: <4ABF10D1.4050807@deployingradius.com>
Date: Sun, 27 Sep 2009 09:14:25 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>>"New attributes SHOULD NOT use this tagging method...". Which is it?
> 
> The tagging scheme in draft-lourdelet does not have the same flaws as
> that described in RFC 2868.  So does the Design Guidelines advice even
> apply here?

  The draft-lourdelet document defines a new data type.  8-bit tag,
followed by 32-bit integer.  While this is arguably better than the RFC
2868 form, it still is a new data type.  And the document discourages
new data types.

  As with most protocol design, there is room for an intelligent
application of checks and balances.  The issues associated with defining
a new data type should be weighed against the issues associated with
re-using a deprecated data type.

  An application of intelligence is suggested.  A thoughtless
application of the guidelines is not appropriate, as is a thoughtless
rejection of it.  I will note that the *only* "MUST" text in the
document is:

   1) provisioning of new services MUST be done in the IETF

   2) service provisioning MUST NOT be done in Access-Reject.

  All other "MUST" text in the documents are quotes from other RFCs.

  Hence, the suggestions of the guidelines documents are SHOULD, SHOULD
NOT, etc.  A reviewer following the guidelines document is perfectly
free to *not* follow its suggestions, if he believes that doing so would
be worse than the alternatives.

  Maybe the document needs to say:

   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  As a result,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.  Reviewers are expected to weigh the cost and
   benefits of following or ignoring the guidelines, as nearly all
   suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
   intent is for the guidelines to help authors create better documents.
   This intent means that reviewers can choose to ignore some of the
   recommendations herein.  When this is done, their review MUST be
   accompanied by an explanation as to why the guidelines were not
   followed, and why following the guidelines would have resulted in
   a worse architecture.

>  Perhaps the Design Guidelilnes document should be more
> clear about exactly what the flaws were in the RFC 2868 scheme that the
> SHOULD NOT applies to. 

  Or, it could say that the tagging mechanism MAY be used when none of
the above limitations apply.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 06:41:33 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_71737ae9-ff56-43fb-9fb2-be9bcc78673d_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Re:  IPv6 Address Option
Date: Sat, 26 Sep 2009 23:41:19 -0700
MIME-Version: 1.0

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>"New attributes SHOULD NOT use this tagging method...".  Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that =
described in RFC 2868.  So does the Design Guidelines advice even apply her=
e?  Perhaps the Design Guidelilnes document should be more clear about exac=
tly what the flaws were in the RFC 2868 scheme that the SHOULD NOT applies =
to. =20







 		 	   		  =

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B"New attributes SHOULD NOT use this tagging method...".  Which is it?=


The tagging scheme in draft-lourdelet does not have the same flaws =
as that described in RFC 2868. =3B So does the Design Guidelines advice=
 even apply here? =3B Perhaps the Design Guidelilnes document should be=
 more clear about exactly what the flaws were in the RFC 2868 scheme that t=
he SHOULD NOT applies to. =3B 







 		 	  =
 		  
=

--_71737ae9-ff56-43fb-9fb2-be9bcc78673d_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 06:41:31 +0000
Message-ID: <4ABF090C.2070401@deployingradius.com>
Date: Sun, 27 Sep 2009 08:41:16 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
>> After all, it's only a draft.  
> 
> Hmm.  That didn't seem to be relevant when you used it a club (its real
> purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

  Are my comments really that influential?

  I've come along in the world.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 06:40:56 +0000
Message-ID: <4ABF08BE.8000904@deployingradius.com>
Date: Sun, 27 Sep 2009 08:39:58 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Actually, _you_ made the claim, I just quoted it.

  Nonsense.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 05:34:36 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'MILES DAVID'" , , , , "'Maglione Roberta'" , 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 12:32:24 +0700
Message-ID: <004801ca3f34$03f249e0$0bd6dda0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aco+tXLUuzshFtPySEyfgZg2ujcYegAfgkdQ
Content-Language: en-us

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto:aland@deployingradius.com] writes:
> >
> >> Glen Zorn wrote:
> >>> Even more interestingly, your latest missive seems to strongly
> imply
> >> that
> >>> adopting the RADIUS Design (Mis-)Guidelines will be a "significant
> >> barrier
> >>> to adoption" of new attributes designed following them...
> >>   Perhaps there's an IETF process to obtain WG consensus and update
> >> published documents?
> >
> > What do you mean?
> 
>   Later documents can update earlier documents.  If the design
> guidelines is as catastrophic as you claim, 

Actually, _you_ made the claim, I just quoted it.

> later documents can update
> it, and define new attributes that don't follow it's recommendations.
> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 03:29:58 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'MILES DAVID'" , , , , "'Maglione Roberta'" , 
Subject: RE: IPv6 Address Option
Date: Sun, 27 Sep 2009 10:27:37 +0700
Message-ID: <001f01ca3f22$96537410$c2fa5c30$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aco+lcBAQ4JbpIirToyCaK9ergH6LgAFM1CQ
Content-Language: en-us

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > ... but draft-ietf-radext-design-08, section 2.1.2 says (talking
> about
> > the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT
> use
> > this tagging method...".  Which is it?
> 
>   I suggest racing against the design guidelines document.  

What a great idea!  Since the Mis-Guidelines draft is in IESG evaluation &
our draft has yet to be accepted as a WG item, it's a race we're sure to
win!  A more likely scenario: we change our draft to match your "review",
then the Mis-Guidelines draft is published as an ACP (Alan's Current
Practice) & presto, we get to change it again.  It would be a classic of
obstructionism, if only it weren't so obvious.

> After all, it's only a draft.  

Hmm.  That didn't seem to be relevant when you used it a club (its real
purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

...



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 27 Sep 2009 00:22:37 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_"
From: Bernard Aboba 
To: , "radiusext@ops.ietf.org" , "David B. Nelson" 
CC: , Mark Townsley 
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 17:21:27 -0700
MIME-Version: 1.0

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> A few months back some of us expressed a desire to proceed with the
> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
> item.=20

On June 25=2C 2009 there was a WG call for interest in the document:=20
http://ops.ietf.org/lists/radiusext/2009/msg00273.html

Only one person other than yourself and the authors replied to the call for=
 interest.=20

In addition=2C the document has not been revised in response to WG comments=
.=20

> In the recent Broadband Forum meeting in Tokyo it was announced
> that the BBF will seek to finalize their document on IPv6 for PPP
> environments (to which I am co-editor). With the lack of some essential
> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
> a hard place.

If there was interest from the Broadband Forum=2C why has noone bothered to
respond to the call for interest or to revise the document?=20

> Delaying the IPv6 for PPP document much beyond November is not an option

If that is the case=2C why are the concerned parties not doing more to move=
 it forward?=20

> I am happy to work with the current authors to create a draft which can b=
e fast tracked.

If you're volunteering to act as editor=2C that would be great.  Next step =
would be to issue a=20
version of the document addressing outstanding comments.  We can then discu=
ss the=20
document at the October 13 Virtual Interim meeting.=20

 		 	   		  =

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B A few months back some of us expressed a desire to proceed with the<=
br>>=3B draft-lourdelet-radext-ipv6-access-01 and recommend its adoption =
as a WG
>=3B item. 

On June 25=2C 2009 there was a WG call for =
interest in the document: 
http://ops.ietf.org/lists/radiusext/2009/msg0=
0273.html

Only one person other than yourself and the authors replie=
d to the call for interest. 

In addition=2C the document has not bee=
n revised in response to WG comments. 

>=3B In the recent Broadban=
d Forum meeting in Tokyo it was announced
>=3B that the BBF will seek =
to finalize their document on IPv6 for PPP
>=3B environments (to which=
 I am co-editor). With the lack of some essential
>=3B RADIUS AVP (suc=
h as IPv6-Address-Option) we are stuck between a rock and
>=3B a hard =
place.

If there was interest from the Broadband Forum=2C why has noo=
ne bothered to
respond to the call for interest or to revise the documen=
t? 

>=3B Delaying the IPv6 for PPP document much beyond November i=
s not an option

If that is the case=2C why are the concerned parties=
 not doing more to move it forward? 

>=3B I am happy to work with =
the current authors to create a draft which can be fast tracked.

If =
you're volunteering to act as editor=2C that would be great. =3B Next s=
tep would be to issue a 
version of the document addressing outstanding =
comments. =3B We can then discuss the 
document at the October 13 Vi=
rtual Interim meeting. 

 		 	   		  
=

--_bd30916f-74d7-4ca4-a8f3-b4d85b8895db_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 26 Sep 2009 14:28:04 +0000
Message-ID: <4ABE24BE.20604@deployingradius.com>
Date: Sat, 26 Sep 2009 16:27:10 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Alan DeKok [mailto:aland@deployingradius.com] writes:
> 
>> Glen Zorn wrote:
>>> Even more interestingly, your latest missive seems to strongly imply
>> that
>>> adopting the RADIUS Design (Mis-)Guidelines will be a "significant
>> barrier
>>> to adoption" of new attributes designed following them...
>>   Perhaps there's an IETF process to obtain WG consensus and update
>> published documents?
> 
> What do you mean?

  Later documents can update earlier documents.  If the design
guidelines is as catastrophic as you claim, later documents can update
it, and define new attributes that don't follow it's recommendations.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 26 Sep 2009 13:11:03 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" 
Cc: "'MILES DAVID'" , , , , "'Maglione Roberta'" , 
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 20:09:11 +0700
Message-ID: <000b01ca3eaa$9af96b00$d0ec4100$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aco+l0hzmeJwAV8GT7uZdad8Ro+aPgAEyg8A
Content-Language: en-us

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Even more interestingly, your latest missive seems to strongly imply
> that
> > adopting the RADIUS Design (Mis-)Guidelines will be a "significant
> barrier
> > to adoption" of new attributes designed following them...
> 
>   Perhaps there's an IETF process to obtain WG consensus and update
> published documents?

What do you mean?



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 26 Sep 2009 10:51:41 +0000
Message-ID: <4ABDF224.9070307@deployingradius.com>
Date: Sat, 26 Sep 2009 12:51:16 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Even more interestingly, your latest missive seems to strongly imply that
> adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
> to adoption" of new attributes designed following them...

  Perhaps there's an IETF process to obtain WG consensus and update
published documents?

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 26 Sep 2009 10:40:52 +0000
Message-ID: <4ABDEF91.5080701@deployingradius.com>
Date: Sat, 26 Sep 2009 12:40:17 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Glen Zorn 
CC: 'MILES DAVID' ,  radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  'Maglione Roberta' , townsley@cisco.com
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> ... but draft-ietf-radext-design-08, section 2.1.2 says (talking about
> the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT use
> this tagging method...".  Which is it?  

  I suggest racing against the design guidelines document.  After all,
it's only a draft.  If the IPv6 document can get published first, then
the design guidelines matter a lot less.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 26 Sep 2009 10:10:15 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" , "'MILES DAVID'" 
Cc: , , , "'Maglione Roberta'" , 
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 17:08:56 +0700
Message-ID: <000401ca3e91$6b916070$42b42150$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aco+ed/JwFhVVLTOTAO3awmb7omv2gACINUQAAOSq0A=
Content-Language: en-us

I wrote:

> Alan DeKok [mailto://aland@deployingradius.com] writes:
> 
> >   Is there a response to my review?
> >
> > http://ops.ietf.org/lists/radiusext/2009/msg00401.html
> >
> >   Addressing the minor issues brought up in the review would allow
> > server implementations to support the document by simply updating
> their
> > dictionaries.  As it stands now, new data types will have to be
> > defined,
> > which can be a significant barrier to adoption.
> 
> In your review you say "Defining a tag field *and* a 32-bit integer
> means
> that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section
> 3.1 for the historical definition. It would seem to be OK to have a 24-
> bit
> lifetime.  That would allow everyone to use this attribute by simply
> updating their dictionaries, rather than writing new code to handle a
> new
> format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking
> about
> the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT
> use
> this tagging method...".  Which is it?

Even more interestingly, your latest missive seems to strongly imply that
adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
to adoption" of new attributes designed following them...




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 26 Sep 2009 09:55:26 +0000
From: "Glen Zorn" 
To: "'Alan DeKok'" , "'MILES DAVID'" 
Cc: , , , "'Maglione Roberta'" , 
Subject: RE: IPv6 Address Option
Date: Sat, 26 Sep 2009 16:53:34 +0700
Message-ID: <000301ca3e8f$46331a00$d2994e00$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aco+ed/JwFhVVLTOTAO3awmb7omv2gACINUQ
Content-Language: en-us

Alan DeKok [mailto://aland@deployingradius.com] writes:

>   Is there a response to my review?
> 
> http://ops.ietf.org/lists/radiusext/2009/msg00401.html
> 
>   Addressing the minor issues brought up in the review would allow
> server implementations to support the document by simply updating their
> dictionaries.  As it stands now, new data types will have to be
> defined,
> which can be a significant barrier to adoption.

In your review you say "Defining a tag field *and* a 32-bit integer means
that you're
re-defining the meaning of a tag + integer attribute.  See RFC 2868, Section
3.1 for the historical definition. It would seem to be OK to have a 24-bit
lifetime.  That would allow everyone to use this attribute by simply
updating their dictionaries, rather than writing new code to handle a new
format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking about
the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT use
this tagging method...".  Which is it?  

...


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 26 Sep 2009 07:18:08 +0000
Message-ID: <4ABDBFE5.4050406@deployingradius.com>
Date: Sat, 26 Sep 2009 09:16:53 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: MILES DAVID 
CC: radiusext@ops.ietf.org, Bernard_Aboba@hotmail.com,  d.b.nelson@comcast.net,  Maglione Roberta , townsley@cisco.com
Subject: Re: IPv6 Address Option
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  Is there a response to my review?

http://ops.ietf.org/lists/radiusext/2009/msg00401.html

  Addressing the minor issues brought up in the review would allow
server implementations to support the document by simply updating their
dictionaries.  As it stands now, new data types will have to be defined,
which can be a significant barrier to adoption.

MILES DAVID wrote:
> Folk,
> 
> A few months back some of us expressed a desire to proceed with the
> draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
> item. In the recent Broadband Forum meeting in Tokyo it was announced
> that the BBF will seek to finalize their document on IPv6 for PPP
> environments (to which I am co-editor). With the lack of some essential
> RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
> a hard place.
> 
> Delaying the IPv6 for PPP document much beyond November is not an option
> for a large number of operators who wish to get some IPv6 deployment
> going. With this goal in mind I ask the WG and chairs to adopt this
> draft as a starting point with a goal of getting to WGLC within the
> coming months (after Hiroshima IETF). If it needs to be simplified down
> to the essential AVP I am happy to work with the current authors to
> create a draft which can be fast tracked.
> 
> The alternatives are ugly IMO
> 
> 
> Regards
> 
> -David Miles
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
> 
> 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 24 Sep 2009 21:30:35 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_315b0f9e-25cb-427c-92e0-dfd18f076caf_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG Virtual Interim Agenda:  October 13, 2009
Date: Thu, 24 Sep 2009 14:29:22 -0700
MIME-Version: 1.0

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




Agenda
Meeting agenda is available here:=20
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt

Slides
Slides are available for download here:=20
http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/

AUDIO INFORMATION=20

To
join a meeting from your phone=2C dial in using the following information:

            Phone:   +18883203585 [English]

            Phone:   +14257063500 [English]

            Find a local
phone number for your region

=20

            Conference ID:    9182049

            Passcode:           Passcode is not required.

            Note: If you have an account on this
corporate network=2C use your PIN to join. Have you set
your PIN?
Web Conferencing information (optional)
To join the online meeting=2C click on the following URL:=20

Join the meeting

 To install the Office Live Meeting client click here.=20

TROUBLESHOOTING=20

Unable
to join the meeting?  Start Office Live
Meeting and join the meeting with the following information:

            Meeting ID:        63840ffb128647eca56d51898b461c42

            Entry Code:        6650

            Location:            meet:sip:bernarda@microsoft.com=3Bgruu=3Bo=
paque=3Dapp:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf-key=3D665=
0

=20

If
you still cannot enter the meeting=2C contact support:=20



Live Meeting Support



 		 	   		  =

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






=



Agenda

Meeting agenda is available here: 
http://www.drizzle.com/~aboba/RA=
DEXT/oct-virtual-interim.txt
<=
/span>
<=
span style=3D"font-family: "=3BTahoma"=3B=2C"=3Bsans-serif"=
=3B=3B color: rgb(0=2C 77=2C 128)=3B">
Slides

S=
lides are available for download here: 
http://www.drizzle.com/~aboba/RADEXT/oct_virtu=
al_interim/

AUDIO INFOR=
MATION 



To
join a meeting from your phone=2C dial in using the following information:<=
o:p>



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Phone: =
=3B =3B +18883203585 [English]



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Phone: =
=3B =3B +14257063500 [English]



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Find a local
phone number for your region



 =3B



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Conference ID: =3B =3B =3B 9182049



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Passcode:&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3B =3B =
=3B Passcode is not required.



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Note: If you have an account =
on this
corporate network=2C use your PIN to join. Have you set
your PIN?

<=
/p>
Web Conferencing information (optional)<=
/b>

To join the online=
 meeting=2C click on the following URL: 



Join the meeting



 =3B
To install=
 the Office Live Meeting client click here. 

=

TROUBLESHOOTING 



Unable
to join the meeting? =3B Start Office Live
Meeting and join the meeting with the following information:



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Meeting ID:&=
nbsp=3B =3B =3B =3B =3B =3B =3B 63840ffb1286=
47eca56d51898b461c42



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Entry Code:&=
nbsp=3B =3B =3B =3B =3B =3B =3B 6650



 =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B Location:&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3B =3B =
=3B =3B =
meet:sip:bernarda@microsoft.com=3Bgruu=3Bopaque=3Dapp:conf:focus:id:63840ff=
b128647eca56d51898b461c42%3Fconf-key=3D6650



 =3B



If
you still cannot enter the meeting=2C contact support: 




Live Meeting Support<=
/span>





 		 	   		  
=

--_315b0f9e-25cb-427c-92e0-dfd18f076caf_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 23 Sep 2009 10:48:50 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: IPv6 Address Option
Date: Wed, 23 Sep 2009 18:47:34 +0800
Message-ID: <986DCE2E44129444B6435ABE8C9E424D02DC1328@SGSINSMBS02.ad4.ad.alcatel.com>
Thread-Topic: IPv6 Address Option
Thread-Index: Aco8O0FDrpRBcz7QSkaHOfeWkXrtAQ==
From: "MILES DAVID" 
To: , , 
Cc: "Maglione Roberta" , 

Folk,

A few months back some of us expressed a desire to proceed with the
draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
item. In the recent Broadband Forum meeting in Tokyo it was announced
that the BBF will seek to finalize their document on IPv6 for PPP
environments (to which I am co-editor). With the lack of some essential
RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
a hard place.

Delaying the IPv6 for PPP document much beyond November is not an option
for a large number of operators who wish to get some IPv6 deployment
going. With this goal in mind I ask the WG and chairs to adopt this
draft as a starting point with a goal of getting to WGLC within the
coming months (after Hiroshima IETF). If it needs to be simplified down
to the essential AVP I am happy to work with the current authors to
create a draft which can be fast tracked.

The alternatives are ugly IMO


Regards

-David Miles

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 15:54:32 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_"
From: Bernard Aboba 
To: Alan DeKok 
CC: Jari Arkko , "dromasca@avaya.com" , , "David B. Nelson" , "radiusext@ops.ietf.org" 
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 08:54:08 -0700
MIME-Version: 1.0

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>    Note that the Vendor type field in the recommended VSA format is only
>    a single octet=2C like the RADIUS type field.  While this limitation
>    results in an efficient encoding=2C there are situations in which a
>    vendor or SDO will eventually wish to define more than 255
>    attributes.  Also=2C an SDO can be comprised of multiple subgroups=2C
>    each of whom can desire autonomy over the definition of attributes
>    within their group.
>=20
>    These desires have led vendors to define the following non-standard
>    VSA formats:

How about this?

"Note that the Vendor type field in the recommended VSA format is only
a single octet=2C like the RADIUS type field.  While this limitation
results in an efficient encoding=2C there are situations in which a
vendor or SDO will eventually wish to define more than 255
attributes.  Also=2C an SDO can be comprised of multiple subgroups=2C
each of whom can desire autonomy over the definition of attributes
within their group.  The most interoperable way to address these
issues is for the vendor or SDO to request allocation of multiple
Vendor identifiers.=20

However=2C instead of doing this=2C vendors have defined the following
non-standard VSA formats:"

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B    Note that the Vendor type field in the recommended VSA format is =
only
>=3B    a single octet=2C like the RADIUS type field.  While this=
 limitation
>=3B    results in an efficient encoding=2C there are situ=
ations in which a
>=3B    vendor or SDO will eventually wish to define=
 more than 255
>=3B    attributes.  Also=2C an SDO can be comprised of=
 multiple subgroups=2C
>=3B    each of whom can desire autonomy over t=
he definition of attributes
>=3B    within their group.
>=3B 
=
>=3B    These desires have led vendors to define the following non-standa=
rd
>=3B    VSA formats:

How about this?

"Note that the V=
endor type field in the recommended VSA format is only
a single octet=2C=
 like the RADIUS type field.  While this limitation
results in an effici=
ent encoding=2C there are situations in which a
vendor or SDO will event=
ually wish to define more than 255
attributes.  Also=2C an SDO can be co=
mprised of multiple subgroups=2C
each of whom can desire autonomy over t=
he definition of attributes
within their group. =3B The most interop=
erable way to address these
issues is for the vendor or SDO to request a=
llocation of multiple
Vendor identifiers. 

However=2C instead of =
doing this=2C vendors have defined the following
non-standard VSA format=
s:"

=

--_63f6cdf9-1d47-4782-a1a7-5a2e6f1f2d2e_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 15:51:31 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_939f895e-c564-4eec-b908-939ab189ece1_"
From: Bernard Aboba 
To: Alan DeKok 
CC: Jari Arkko , "dromasca@avaya.com" , , "David B. Nelson" , "radiusext@ops.ietf.org" 
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 08:51:10 -0700
MIME-Version: 1.0

--_939f895e-c564-4eec-b908-939ab189ece1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>    All of these formats are NOT RECOMMENDED.  All VSA formats that do
>    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
>    RECOMMENDED formats include Vendor types of more than 8 bits=2C Vendor
>    lengths of less than 8 bits=2C Vendor lengths of more than 8 bits=2C a=
nd
>    Vendor-Specific contents that are not in Type-Length-Value format.

How about this?=20

All VSA schemes that do not follow the [RFC2865] recommendations
are NOT RECOMMENDED since these formats will typically not be
implementable without RADIUS server code changes.  This includes all=20
the above formats=2C as well as Vendor types of more than 8 bits=2C vendor=
=20
lengths of less than 8 bits=2C vendor lengths of more than 8 bits and=20
Vendor-Specific contents that are not in Type-Length-Value format.=20

--_939f895e-c564-4eec-b908-939ab189ece1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B    All of these formats are NOT RECOMMENDED.  All VSA formats that d=
o
>=3B    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT>=3B    RECOMMENDED formats include Vendor types of more than 8 bits=2C=
 Vendor
>=3B    lengths of less than 8 bits=2C Vendor lengths of more =
than 8 bits=2C and
>=3B    Vendor-Specific contents that are not in Ty=
pe-Length-Value format.

How about this? 

All VSA schemes that=
 do not follow the [RFC2865] recommendations
are NOT RECOMMENDED since t=
hese formats will typically not be
implementable without RADIUS server c=
ode changes. =3B This includes all 
the above formats=2C as well as =
Vendor types of more than 8 bits=2C vendor 
lengths of less than 8 bits=
=2C vendor lengths of more than 8 bits and 
Vendor-Specific contents tha=
t are not in Type-Length-Value format. 

=

--_939f895e-c564-4eec-b908-939ab189ece1_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 15:46:46 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_ef2723cd-02b5-4019-9e50-c7be4368053d_"
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: REMINDER:  Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item
Date: Thu, 17 Sep 2009 08:45:07 -0700
MIME-Version: 1.0

--_ef2723cd-02b5-4019-9e50-c7be4368053d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Deployment experience with RADIUS over TLS indicates that is useful
> for inter-server communication=2C such as inter-domain proxying across
> the Internet.  The large amounts of traffic=2C and long-lived
> connections are a good fit for TCP transport.  These situations
> commonly also require complete data privacy that can be supplied by
> TLS.
>=20
> The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to
> server communication is a bad fit=2C as there is usually insufficient
> traffic to warrant the use of TCP.  Using "bare" TCP for inter-server
> communication is a bad fit=2C as it provides for no data privacy.  The
> only valid use-case for "bare" TCP=2C therefore=2C is on private=2C secur=
ed
> networks where there is simultaneously a large amount of traffic=2C and
> no need for data integrity or privacy.


How about this?=20



"Deployment experience with RADIUS over TLS indicates that it is=20

most useful for inter-server communication=2C such as inter-domain
communication between proxies.  These situations benefit from
the confidentiality and ciphersuite negotiation that can be provided=20
by TLS. Since TLS is already widely available within the operating=20
systems used by proxies=2C implementation barriers are low.=20

RADIUS over TCP has a similar set of use cases.  Use of TCP as
a transport between a NAS and RADIUS server is a poor fit=2C
since as noted in [RFC3539]=2C there is likely to be insufficient traffic f=
or=20
the congestion window to remain above the minimum value on a
long-term basis.  The result is an increase in packets due to ACKs=20
as compared to UDP=2C without a corresponding set of benefits.=20

In server-server communications the traffic levels in both
directions are typically high enough to support a larger
congestion window as well as ACK piggy-backing. =20
Through use of an application-layer watchdog as described
in [RFC3539]=2C it is possible to address the objections
to reliable transport described in [RFC2865] Section 2.4.=20
However=2C in these scenarios "bare" TCP does not provide for=20
confidentiality or enable negotiation of stronger ciphersuites
than are available in RADIUS.=20

As a result of these considerations=2C use of RADIUS over
TCP SHOULD be restricted to situations where RADIUS over
TLS is employed.  RADIUS over "bare" TCP is NOT RECOMMENDED."

--_ef2723cd-02b5-4019-9e50-c7be4368053d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B Deployment experience with RADIUS over TLS indicates that is useful<=
br>>=3B for inter-server communication=2C such as inter-domain proxying a=
cross
>=3B the Internet.  The large amounts of traffic=2C and long-liv=
ed
>=3B connections are a good fit for TCP transport.  These situation=
s
>=3B commonly also require complete data privacy that can be supplie=
d by
>=3B TLS.
>=3B 
>=3B The use of "bare" TCP has fewer us=
e-cases.  Using TCP for NAS to
>=3B server communication is a bad fit=
=2C as there is usually insufficient
>=3B traffic to warrant the use o=
f TCP.  Using "bare" TCP for inter-server
>=3B communication is a bad =
fit=2C as it provides for no data privacy.  The
>=3B only valid use-ca=
se for "bare" TCP=2C therefore=2C is on private=2C secured
>=3B networ=
ks where there is simultaneously a large amount of traffic=2C and
>=3B=
 no need for data integrity or privacy.


How about this? 



"Deployment experience with RADIUS over TLS indicates that it is 

most useful for inter-server communication=2C such as inter-domain
commu=
nication between proxies. =3B These situations benefit from
the conf=
identiality and ciphersuite negotiation that can be provided 
by TLS. Si=
nce TLS is already widely available within the operating 
systems used b=
y proxies=2C implementation barriers are low. 

RADIUS over TCP has a=
 similar set of use cases. =3B Use of TCP as
a transport between a N=
AS and RADIUS server is a poor fit=2C
since as noted in [RFC3539]=2C the=
re is likely to be insufficient traffic for 
the congestion window to re=
main above the minimum value on a
long-term basis. =3B The result is=
 an increase in packets due to ACKs 
as compared to UDP=2C without a cor=
responding set of benefits. 

In server-server communications the tra=
ffic levels in both
directions are typically high enough to support a la=
rger
congestion window as well as ACK piggy-backing. =3B 
Through=
 use of an application-layer watchdog as described
in [RFC3539]=2C it is=
 possible to address the objections
to reliable transport described in [=
RFC2865] Section 2.4. 
However=2C in these scenarios "bare" TCP does not=
 provide for 
confidentiality or enable negotiation of stronger ciphersu=
ites
than are available in RADIUS. 

As a result of these consider=
ations=2C use of RADIUS over
TCP SHOULD be restricted to situations wher=
e RADIUS over
TLS is employed. =3B RADIUS over "bare" TCP is NOT REC=
OMMENDED."

=

--_ef2723cd-02b5-4019-9e50-c7be4368053d_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 15:08:45 +0000
Message-ID: <4AB250B7.4000804@deployingradius.com>
Date: Thu, 17 Sep 2009 17:07:35 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" 
CC: Jari Arkko ,  Bernard Aboba , "Weber, Gregory D (Greg)" ,  "David B. Nelson" , radext mailing list 
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Romascanu, Dan (Dan) wrote:
> This looks acceptable to me. 
> 
> Alan, do you plan to respin the I-D? 

  Yes.  I can issue one tomorrow.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 12:10:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Date: Thu, 17 Sep 2009 14:08:07 +0200
Message-ID: 
Thread-Topic: Jari's DISCUSS on draft-ietf-radext-design-07.txt
thread-index: Aco3gYeW3QJ1aUVGTdiuPk2gsrbUSAADecZw
From: "Romascanu, Dan (Dan)" 
To: "Jari Arkko" , "Alan DeKok" 
Cc: "Bernard Aboba" , "Weber, Gregory D (Greg)" , "David B. Nelson" , "radext mailing list" 

This looks acceptable to me.=20

Alan, do you plan to respin the I-D?=20

Thanks and Regards,

Dan
=20

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]=20
> Sent: Thursday, September 17, 2009 1:28 PM
> To: Alan DeKok
> Cc: Bernard Aboba; Romascanu, Dan (Dan); Weber, Gregory D=20
> (Greg); David B. Nelson; 'radext mailing list'
> Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
>=20
> This resolves my Discuss.
>=20
> But do you want to include a strong recommendation to not use=20
> these formats, if the plan is to shortly thereafter publish=20
> an update of the VSA base format to use 16 bits? Perhaps=20
> slightly weaker language would be better here. E.g., "These=20
> formats are currently NOT RECOMMENDED, though work is ongoing=20
> to possible update the current VSA format."
>=20
> Jari
>=20
> Alan DeKok wrote:
> > Bernard Aboba wrote:
> >  =20
> >> As a result of the change, what will Section 2.2 look like?
> >>    =20
> >
> >   Updated text after the first paragraph below:
> >
> >
> >    Note that the Vendor type field in the recommended VSA=20
> format is only
> >    a single octet, like the RADIUS type field.  While this=20
> limitation
> >    results in an efficient encoding, there are situations in which a
> >    vendor or SDO will eventually wish to define more than 255
> >    attributes.  Also, an SDO can be comprised of multiple subgroups,
> >    each of whom can desire autonomy over the definition of=20
> attributes
> >    within their group.
> >
> >    These desires have led vendors to define the following=20
> non-standard
> >    VSA formats:
> >
> >    * Vendor types of 16 bits, followed by an 8 bit length and
> >      then attribute-specific data.
> >
> >    * Vendor types of 32 bits, followed by no length field, and
> >      then attribute-specific data.
> >
> >    * Vendor types of the RFC format, but where some VSAs are
> >      defined as "grouped" or TLV attributes.  These attributes
> >      are then used to carry sub-attributes.
> >
> >    * "Bare" ASCII strings that immediately follow the Vendor-Id,
> >       without using a Vendor type or Vendor length.
> >
> >    All of these formats are NOT RECOMMENDED.  All VSA=20
> formats that do
> >    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
> >    RECOMMENDED formats include Vendor types of more than 8=20
> bits, Vendor
> >    lengths of less than 8 bits, Vendor lengths of more than=20
> 8 bits, and
> >    Vendor-Specific contents that are not in=20
> Type-Length-Value format.
> >
> >    Although [RFC2865] does not mandate it, implementations commonly
> >    assume that the Vendor Id can be used as a key to=20
> determine the on-
> >    the-wire format of a VSA.  Vendors therefore SHOULD NOT=20
> use multiple
> >    formats for VSAs that are associated with a particular=20
> Vendor Id.  A
> >    vendor wishing to use multiple VSA formats, SHOULD=20
> request one Vendor
> >    Id for each VSA format that they will use.
> >
> >   Alan DeKok.
> >
> > --
> > to unsubscribe send a message to=20
> radiusext-request@ops.ietf.org with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: 
> >
> >  =20
>=20
>=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 10:28:20 +0000
Message-ID: <4AB20F2A.60003@piuha.net>
Date: Thu, 17 Sep 2009 13:27:54 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Alan DeKok 
CC: Bernard Aboba ,  "dromasca@avaya.com" , "Weber, Gregory D (Greg)" ,  "David B. Nelson" , 'radext mailing list' 
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This resolves my Discuss.

But do you want to include a strong recommendation to not use these 
formats, if the plan is to shortly thereafter publish an update of the 
VSA base format to use 16 bits? Perhaps slightly weaker language would 
be better here. E.g., "These formats are currently NOT RECOMMENDED, 
though work is ongoing to possible update the current VSA format."

Jari

Alan DeKok wrote:
> Bernard Aboba wrote:
>   
>> As a result of the change, what will Section 2.2 look like?
>>     
>
>   Updated text after the first paragraph below:
>
>
>    Note that the Vendor type field in the recommended VSA format is only
>    a single octet, like the RADIUS type field.  While this limitation
>    results in an efficient encoding, there are situations in which a
>    vendor or SDO will eventually wish to define more than 255
>    attributes.  Also, an SDO can be comprised of multiple subgroups,
>    each of whom can desire autonomy over the definition of attributes
>    within their group.
>
>    These desires have led vendors to define the following non-standard
>    VSA formats:
>
>    * Vendor types of 16 bits, followed by an 8 bit length and
>      then attribute-specific data.
>
>    * Vendor types of 32 bits, followed by no length field, and
>      then attribute-specific data.
>
>    * Vendor types of the RFC format, but where some VSAs are
>      defined as "grouped" or TLV attributes.  These attributes
>      are then used to carry sub-attributes.
>
>    * "Bare" ASCII strings that immediately follow the Vendor-Id,
>       without using a Vendor type or Vendor length.
>
>    All of these formats are NOT RECOMMENDED.  All VSA formats that do
>    not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
>    RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
>    lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
>    Vendor-Specific contents that are not in Type-Length-Value format.
>
>    Although [RFC2865] does not mandate it, implementations commonly
>    assume that the Vendor Id can be used as a key to determine the on-
>    the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
>    formats for VSAs that are associated with a particular Vendor Id.  A
>    vendor wishing to use multiple VSA formats, SHOULD request one Vendor
>    Id for each VSA format that they will use.
>
>   Alan DeKok.
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>
>   


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 10:06:57 +0000
Message-ID: <4AB20A1C.906@deployingradius.com>
Date: Thu, 17 Sep 2009 12:06:20 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: Jari Arkko ,  "dromasca@avaya.com" , "Weber, Gregory D (Greg)" ,  "David B. Nelson" , 'radext mailing list' 
Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> As a result of the change, what will Section 2.2 look like?

  Updated text after the first paragraph below:


   Note that the Vendor type field in the recommended VSA format is only
   a single octet, like the RADIUS type field.  While this limitation
   results in an efficient encoding, there are situations in which a
   vendor or SDO will eventually wish to define more than 255
   attributes.  Also, an SDO can be comprised of multiple subgroups,
   each of whom can desire autonomy over the definition of attributes
   within their group.

   These desires have led vendors to define the following non-standard
   VSA formats:

   * Vendor types of 16 bits, followed by an 8 bit length and
     then attribute-specific data.

   * Vendor types of 32 bits, followed by no length field, and
     then attribute-specific data.

   * Vendor types of the RFC format, but where some VSAs are
     defined as "grouped" or TLV attributes.  These attributes
     are then used to carry sub-attributes.

   * "Bare" ASCII strings that immediately follow the Vendor-Id,
      without using a Vendor type or Vendor length.

   All of these formats are NOT RECOMMENDED.  All VSA formats that do
   not follow [RFC2865] are NOT RECOMMENDED.  Examples of NOT
   RECOMMENDED formats include Vendor types of more than 8 bits, Vendor
   lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
   Vendor-Specific contents that are not in Type-Length-Value format.

   Although [RFC2865] does not mandate it, implementations commonly
   assume that the Vendor Id can be used as a key to determine the on-
   the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
   formats for VSAs that are associated with a particular Vendor Id.  A
   vendor wishing to use multiple VSA formats, SHOULD request one Vendor
   Id for each VSA format that they will use.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 17 Sep 2009 09:44:23 +0000
Message-ID: <4AB204BE.3090305@deployingradius.com>
Date: Thu, 17 Sep 2009 11:43:26 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> [BA] My impression was that this document (like RADIUS over TLS and
> RADIUS over DTLS) was targeted for Experimental status.

  Fixed.

> Abstract
...
> [BA] It might be worth stating that this specification was developed
> primarily for addressing the transport issues inherent in RADIUS over
> TLS, and that it is not intended for use by itself.   

  That text is also in Section 1.1, but it doesn't hurt to emphasize it
here.

> [BA] Determining when a client or server is down is not automatically
> solved by choice of a reliable transport.

  TCP can provide a positive statement when a connection is down.

> For example, without an application layer watchdog, an application
> relying on TCP would typically need to wait
> until the connection timed out before trying another server.

  Yes.  Or, receiving a FIN when a connection is closed.

>  This is
> the problem identified by RFC 2865, which talks about UDP be used for
> faster failover than would be permitted by TCP without a watchdog. 
> However, failover as envisaged by RFC 2865 does not require deducing
> that a server is "down" based on lack of a reply;  doing so would
> require a much longer waiting interval than implementations typically
> provide.  RADIUS over UDP implementations typically don't care whether
> the server is "down" or not; they only care that it hasn't responded
> after set time interval or number of retries.

  For robust proxying, a number of implementations track server state.
They can implement simple checks such as "no response to any packet in
the last 60 seconds".  They can then mark a server as "down", remove it
from any pool of active servers, and refuse to forward *new* packets to it.

>  However, none of this is
> specified in RFC 2865 (or RFC 5080), so the quality of the failover
> algorithm will vary between implementations.  This I think is the
> more relevant point -- lack of a standardized failover algorithm. 
> Presumably, this document can address that problem.

 Hmm... I'm not so sure.  Failover algorithms are hard to get right.
And I don't think that the TCP document is the best place to discuss
general RADIUS failover.

  Defining a TCP watchdog is OK, but that's just referencing RFC 3539.

  Maybe the text should say instead:

* Connectionless transport.  Neither clients nor servers receive
positive statements that a "connection" is down.  This information has
to be deduced instead from the absence of a reply to a request.

> [BA] I would disagree that the failover problem is necessarily minor; 
> in implementations I'm familiar with, developing a stable and reliable
> failover algorithm was a major pain.

  Agreed.

>  With respect to the reasoning
> behind the development of RADIUS over TCP, is the issue really the need
> for a "different set of tradeoffs", or is the issue the different set of
> needs that manifest themselves in proxy-proxy transport situations?

  Both, I think.  Suggested rewording:

As RADIUS is widely deployed, and has been widely deployed for well
over a decade, these issues have been minor in some use-cases, and
problematic in others.  New systems may be interested in choosing a
different set of trade-offs than those outlined in [RFC2865] Section
2.4.  New systems may also be interested in choosing a more reliable
transport for use-cases such as inter-server proxying.  For those
systems, we define RADIUS over TCP.

> [BA] I think you might say a bit more about the applicability of RADIUS
> over "bare" TCP.  For example, that
> it is only useful in proxy-proxy scenarios where the traffic is
> protected by TLS.  The reasons given might include both transport as
> well as security and interoperability concerns.   For example, we have
> seen interoperability problems result in situations where application
> layer protocols can be transported in multiple ways (e.g. SIP), and
> proxy-proxy scenarios can benefit from stronger/more flexible security,
> as envisaged in RADIUS over TLS. 

  How about this text:

Deployment experience with RADIUS over TLS indicates that is useful
for inter-server communication, such as inter-domain proxying across
the Internet.  The large amounts of traffic, and long-lived
connections are a good fit for TCP transport.  These situations
commonly also require complete data privacy that can be supplied by
TLS.

The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to
server communication is a bad fit, as there is usually insufficient
traffic to warrant the use of TCP.  Using "bare" TCP for inter-server
communication is a bad fit, as it provides for no data privacy.  The
only valid use-case for "bare" TCP, therefore, is on private, secured
networks where there is simultaneously a large amount of traffic, and
no need for data integrity or privacy.

  Alan DeKok.


  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 17:53:57 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
Date: Wed, 16 Sep 2009 10:53:40 -0700
MIME-Version: 1.0

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Here are my comments:

=20

Category: Proposed Standards

=20

[BA] My impression was that this document (like RADIUS over TLS and RADIUS =
over DTLS) was targeted for Experimental status.=20

=20

Abstract

   The Remote Authentication Dial In User Server (RADIUS) Protocol has
   traditionally used the User Datagram Protocol (UDP) as it's
   underlying transport layer.  This document defines RADIUS over the
   Transmission Control Protocol (TCP).


[BA] It might be worth stating that this specification was developed primar=
ily for addressing the transport issues inherent in RADIUS over TLS=2C and =
that it is not intended for use by itself.   =20

=20

Section 1

=20

      * Connectionless transport.  Neither clients nor servers can
      reliably detect when the other is down.  This information has to
      be deduced instead from the absence of a reply to a request.


[BA] Determining when a client or server is down is not automatically solve=
d by choice of a reliable transport.

For example=2C without an application layer watchdog=2C an application rely=
ing on TCP would typically need to wait

until the connection timed out before trying another server.  This is the p=
roblem identified by RFC 2865=2C which talks about UDP be used for faster f=
ailover than would be permitted by TCP without a watchdog.  However=2C fail=
over as envisaged by RFC 2865 does not require deducing that a server is "d=
own" based on lack of a reply=3B  doing so would require a much longer wait=
ing interval than implementations typically provide.  RADIUS over UDP imple=
mentations typically don't care whether the server is "down" or not=3B they=
 only care that it hasn't responded after set time interval or number of re=
tries.  However=2C none of this is specified in RFC 2865 (or RFC 5080)=2C s=
o the quality of the failover algorithm will vary between implementations. =
 This I think is the

more relevant point -- lack of a standardized failover algorithm.  Presumab=
ly=2C this document can address that problem.=20

=20

   As RADIUS is widely deployed=2C and has been widely deployed for well
   over a decade=2C these issues are relatively minor.  However=2C new
   systems may be interested in choosing a different set of trade-offs
   than those outlined in [RFC2865] Section 2.4.  For those systems=2C we
   define RADIUS over TCP.


[BA] I would disagree that the failover problem is necessarily minor=3B  in=
 implementations I'm familiar with=2C developing a stable and reliable fail=
over algorithm was a major pain.  With respect to the reasoning behind the =
development of RADIUS over TCP=2C is the issue really the need for a "diffe=
rent set of tradeoffs"=2C or is the issue the different set of needs that m=
anifest themselves in proxy-proxy transport situations?  As described in RF=
C 3539=2C NAS-proxy scenarios do not really benefit from reliable transport=
 because the connection would be likely to run with the minimum congestion =
window most of the time.  As a result=2C using reliable transport just gene=
rates a lot of ACK traffic without making use of the congestion control/win=
dow management benefits of TCP. This is not necessarily the case for proxy-=
proxy transport where the volume may be quite a bit higher. =20

=20

Section 1.1

=20

   The intent of this document is to address transport issues related to
   RadSec [RADSEC].  The use of "bare" TCP transport is NOT RECOMMENDED=2C
   as there has been little implementational or operational experience
   with it.  Additionally=2C [RFC2865] Section 2.4 contains a list of
   reasons why UDP was originally chosen as the transport protocol for
   RADIUS.  UDP SHOULD be used as transport protocol in all cases where
   the rationale given in [RFC2865] Section 2.4 applies.


[BA] I think you might say a bit more about the applicability of RADIUS ove=
r "bare" TCP.  For example=2C that

it is only useful in proxy-proxy scenarios where the traffic is protected b=
y TLS.  The reasons given might include both transport as well as security =
and interoperability concerns.   For example=2C we have seen interoperabili=
ty problems result in situations where application layer protocols can be t=
ransported in multiple ways (e.g. SIP)=2C and proxy-proxy scenarios can ben=
efit from stronger/more flexible security=2C as envisaged in RADIUS over TL=
S. =20

=20

=20

=20

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














Here are my comments:

 =3B

Category: Proposed Standards

 =3B

[BA] My impression was that this =3Bdocument (like RADIUS over TLS and =
RADIUS over DTLS) was targeted for Experimental status. 

 =3B

Abstract

 =3B =3B The Remote Authentication Dial In User Ser=
ver (RADIUS) Protocol has
 =3B =3B traditionally used the User D=
atagram Protocol (UDP) as it's
 =3B =3B underlying transport lay=
er. =3B This document defines RADIUS over the
 =3B =3B Trans=
mission Control Protocol (TCP).


[BA] It might be worth stating that this specification was developed primar=
ily for addressing the transport issues inherent in RADIUS over TLS=2C and =
that it is not intended for use by itself. =3B =3B =3B 

 =3B

Section 1

 =3B

 =3B =3B =3B =3B =3B * Connectionless transport. =
=3B Neither clients nor servers can
 =3B =3B =3B =3B&nbs=
p=3B reliably detect when the other is down. =3B This information has t=
o
 =3B =3B =3B =3B =3B be deduced instead from the a=
bsence of a reply to a request.


[BA] Determining when a client or server is down is not automatically solve=
d by choice of a reliable transport.

For example=2C without an application layer watchdog=2C an application rely=
ing on TCP would typically need to wait

until the connection timed out before trying another server. =3B This i=
s the problem identified by RFC 2865=2C which =3Btalks about UDP be use=
d =3Bfor faster =3Bfailover than would be permitted by =3BTCP w=
ithout a watchdog. =3B However=2C =3Bfailover as envisaged by RFC 2=
865 does not require deducing that a =3Bserver is "down" based on lack =
of a reply=3B =3B =3Bdoing so would require a much longer waiting i=
nterval than implementations typically provide. =3B RADIUS over UDP imp=
lementations typically don't care whether the server is "down" or not=3B th=
ey only care that it hasn't responded after set time interval or number of =
retries. =3B =3BHowever=2C none of this is specified in RFC 2865 (o=
r RFC 5080)=2C so =3Bthe quality of the failover algorithm will vary be=
tween implementations. =3B This I think is the

more relevant point -- lack of a standardized failover algorithm. =3B P=
resumably=2C this document can address that problem. 

 =3B

 =3B =3B As RADIUS is widely deployed=2C and has been widely deploy=
ed for well
 =3B =3B over a decade=2C these issues are relativel=
y minor. =3B However=2C new
 =3B =3B systems may be interest=
ed in choosing a different set of trade-offs
 =3B =3B than those=
 outlined in [RFC2865] Section =3B2.4. =3B For t=
hose systems=2C we
 =3B =3B define RADIUS over TCP.


[BA] I would disagree that the failover problem is necessarily minor=3B&nbs=
p=3B in implementations I'm familiar with=2C developing a stable and reliab=
le failover algorithm was a major pain. =3B With respect to the reasoni=
ng behind the development of RADIUS over TCP=2C is the issue really the nee=
d for a "different set of tradeoffs"=2C or is the issue the =3Bdifferen=
t set of needs that =3Bmanifest themselves in proxy-proxy transport sit=
uations? =3B =3BAs described in RFC 3539=2C NAS-proxy =3Bscenar=
ios do not really benefit from reliable transport because the connection&nb=
sp=3Bwould be likely to =3Brun with =3Bthe minimum congestion windo=
w most of the time. =3B As a result=2C using reliable transport just ge=
nerates a lot of ACK traffic without making use of the congestion control/w=
indow management benefits of TCP. This is not necessarily the case for prox=
y-proxy transport where the volume may be quite a bit higher. =3B 

 =3B

Section 1.1

 =3B

 =3B =3B The intent of this document is to address transport issues=
 related to
 =3B =3B RadSec [RADSEC=
]. =3B The use of "bare" TCP transport is NOT RECOMMENDED=2C=

 =3B =3B as there has been little implementational or operation=
al experience
 =3B =3B with it. =3B Additionally=2C [RFC2865] Section =3B2.4 contains a list of
 =3B&nbs=
p=3B reasons why UDP was originally chosen as the transport protocol for =3B =3B RADIUS. =3B UDP SHOULD be used as transport protocol =
in all cases where
 =3B =3B the rationale given in [RFC2=
865] Section =3B2.4 applies.


[BA] I think you might say a bit more about the =3Bapplicability of&nbs=
p=3BRADIUS over "bare" TCP. =3B For example=2C that

it is only useful in proxy-proxy scenarios where the traffic is protected b=
y TLS. =3B The reasons given might include both transport as well as se=
curity and interoperability concerns. =3B =3B =3BFor example=2C=
 we have seen interoperability problems result in situations where applicat=
ion layer protocols can be transported in multiple ways (e.g. SIP)=2C and p=
roxy-proxy scenarios can benefit from stronger/more flexible security=2C as=
 envisaged in RADIUS over TLS. =3B 

 =3B

 =3B

 =3B

=

--_384ca932-bb65-4eda-8c43-e1d2d6fcb8f0_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 17:52:42 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG Virtual Interim Meeting October 13, 2009
Date: Wed, 16 Sep 2009 10:52:21 -0700
MIME-Version: 1.0

--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








The RADEXT WG will be having a Virtual Interim Meeting on Tuesday=2C Octobe=
r 13=2C 2009 from 8:00 AM - 10:00 AM PDT. =20

Details on the agenda and conference calling parameters for the meeting wil=
l be available here:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt





--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












The RADEXT WG will be havi=
ng a Virtual Interim Meeting on Tuesday=2C October 13=2C 2009 from 8:00 AM =
- 10:00 AM PDT. =3B 

Details on the agenda and conference callin=
g parameters for the meeting will be available here:
http://www.drizzle.=
com/~aboba/RADEXT/oct-virtual-interim.txt





=

--_79fbfb41-a01a-427b-9ae9-80ab64b3d16e_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 17:52:15 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_fd1f39e7-4177-487b-9354-1fa6eb06b008_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT Virtual Interim Agenda - Take One
Date: Wed, 16 Sep 2009 10:51:39 -0700
MIME-Version: 1.0

--_fd1f39e7-4177-487b-9354-1fa6eb06b008_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba 
David Nelson 

Tuesday=2C October 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)


8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Document Status=20

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls




--_fd1f39e7-4177-487b-9354-1fa6eb06b008_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












RADEXT WG Virtual Interim Agen=
da

Chairs: Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B<=
br>David Nelson <=3Bd.b.nelson@comcast.net>=3B

Tuesday=2C Octobe=
r 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)


8:00 AM - 8=
:20 AM  Preliminaries
   Jabber scribe
   Document Status 

Doc=
uments completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Desi=
gn Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org=
/html/draft-ietf-radext-design

Documents Completing WG Last Call (20=
 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
=
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 A=
M Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.or=
g/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over=
 TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draf=
t-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 A=
M - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http:=
//tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - =
9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.or=
g/html/draft-dekok-radext-dtls




=

--_fd1f39e7-4177-487b-9354-1fa6eb06b008_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 16:25:47 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_46b58ef5-5872-4128-808f-149a7751ec96_"
From: Bernard Aboba 
To: "David B. Nelson" , "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 09:24:54 -0700
MIME-Version: 1.0

--_46b58ef5-5872-4128-808f-149a7751ec96_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


+1

> That text looks good to me.



--_46b58ef5-5872-4128-808f-149a7751ec96_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






+1

>=3B That text looks good to me.



=

--_46b58ef5-5872-4128-808f-149a7751ec96_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 15:19:04 +0000
From: "Dave Nelson" 
To: 
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 11:18:19 -0400
Message-ID: <53C1B452056244809265A07DC6AF80F8@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Aco20VSq07zOc9Z7TwSaaP/ze6X38wAD1Yfg

Alan DeKok writes...

>   See the last sentence you quoted:
> 
>    The specification SHOULD
>    NOT define or describe the structure, as discussed above in Section
>    2.1.3.
> 
>   If it's an opaque type, then the format shouldn't be described in a
> RADIUS document.

Right.  Hopefully future authors will take that to heart.  :-)

>   I believe so.  How about breaking those definitions out into a new
> section:
> 
> A.1.2. Transport of Authentication and Security Data
> 
>    Does the data provide authentication and/or security capabilities, as
>    outlined below?  If so, it SHOULD be encapsulated in a [RFC2865]
>    format RADIUS attribute.  It SHOULD NOT be encapsulated in a
>    [RFC2865] format RADIUS VSA.
> 
>       * Complex data types that carry authentication methods which
>         RADIUS servers are expected to parse and verify as part of
>         an authentication process.
> 
>       * Complex data types that carry security information intended
>         to increase the security of the RADIUS protocol itself.
> 
>    Any data type carrying authentication and/or security data that is
>    not meant to be parsed by a RADIUS server is an "opaque data type",
>    as defined below.

That text looks good to me.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 13:27:28 +0000
Message-ID: <4AB0E78F.60107@deployingradius.com>
Date: Wed, 16 Sep 2009 15:26:39 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Dave Nelson 
CC: radiusext@ops.ietf.org
Subject: Re: Issue 313:  Security Exemption
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
>>     * define a complex data type
>>     * that the RADIUS server and/or client will not treat as opaque data
>>       (see Section A.1.3)
> 
> Uh, there is no Appendix A.1.3 in the -08 version.  Is that now A.1.2?

  Yes.

> What's the status of an attribute if the author claims that it can be opaque
> to a RADIUS server implementation, but the format of the data payload
> contained in the attribute is not defined in any other document, but rather
> defined, in standard RADIUS attribute fashion, within the RADIUS extension
> document itself?  Does that qualify for meeting the opaqueness test of
> A.1.2?

  See the last sentence you quoted:

   The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

  If it's an opaque type, then the format shouldn't be described in a
RADIUS document.

>>   If the RADIUS server has to parse it, then complex attributes are
>> allowed for authentication and security...
> 
> I want to further nail down these two words: authentication, security.
> 
> Does authentication mean that the attribute is used to implement a RADIUS
> Authentication Method?
> 
> Does security means that the attribute is used to provide message integrity
> or message confidentiality for the RADIUS datagram itself?
> 
> Those extended definitions match what I think is the intent.

  I believe so.  How about breaking those definitions out into a new
section:

A.1.2. Transport of Authentication and Security Data

   Does the data provide authentication and/or security capabilities, as
   outlined below?  If so, it SHOULD be encapsulated in a [RFC2865]
   format RADIUS attribute.  It SHOULD NOT be encapsulated in a
   [RFC2865] format RADIUS VSA.

      * Complex data types that carry authentication methods which
        RADIUS servers are expected to parse and verify as part of
        an authentication process.

      * Complex data types that carry security information intended
        to increase the security of the RADIUS protocol itself.

   Any data type carrying authentication and/or security data that is
   not meant to be parsed by a RADIUS server is an "opaque data type",
   as defined below.

> On the other hand, security could mean all sorts of things.  It could be a
> key-wrap attribute for a key to be used in the NAS or the attached
> end-point.

  e.g. the MS-MPPE-keys... but those could fit into the standard RADIUS
data model with a bit of tweaking.

> I'd really like to see this definitional issue tightened up before the next
> draft version is issued.

  Suggested text is above.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 12:29:15 +0000
From: "Dave Nelson" 
To: 
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 08:28:50 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcowwS1Ia7t2arAPQAGrcQPLaTDGnAGBf/Ag

Alan DeKok wrote...
> 
>   ?
> 
>    Does the attribute:
> 
>     * define a complex data type
>     * that the RADIUS server and/or client will not treat as opaque data
>       (see Section A.1.3)

Uh, there is no Appendix A.1.3 in the -08 version.  Is that now A.1.2?

A.1.2. Opaque data types

   Does the attribute encapsulate an existing data structure defined
   outside of the RADIUS specifications?  Can the attribute be treated
   as opaque data by RADIUS servers (including proxies?)  If both
   questions can be answered affirmatively, a complex structure MAY be
   used in a RADIUS specification.

   The specification of the attribute SHOULD define the encapsulating
   attribute to be of type String.  The specification SHOULD refer to an
   external document defining the structure.  The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

What's the status of an attribute if the author claims that it can be opaque
to a RADIUS server implementation, but the format of the data payload
contained in the attribute is not defined in any other document, but rather
defined, in standard RADIUS attribute fashion, within the RADIUS extension
document itself?  Does that qualify for meeting the opaqueness test of
A.1.2?
 
>   If the RADIUS server can treat it as opaque data, then it falls under
> the purview of A.1.3.  It is permitted, independent of it being used for
> authentication, security, or anything else.
> 
>   If the RADIUS server has to parse it, then complex attributes are
> allowed for authentication and security...

I want to further nail down these two words: authentication, security.

Does authentication mean that the attribute is used to implement a RADIUS
Authentication Method?

Does security means that the attribute is used to provide message integrity
or message confidentiality for the RADIUS datagram itself?

Those extended definitions match what I think is the intent.

On the other hand, security could mean all sorts of things.  It could be a
key-wrap attribute for a key to be used in the NAS or the attached
end-point.  It could be a security policy such as access control information
or a mandatory cipher-suite.  I could go on.  Lots and lots of things fall
under the moniker of security.

I'd really like to see this definitional issue tightened up before the next
draft version is issued.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 16 Sep 2009 12:15:13 +0000
From: "Dave Nelson" 
To: 
Subject: RE: Issue 313:  Security Exemption
Date: Wed, 16 Sep 2009 08:13:54 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcowxFRURay+VInzS6yC3o/iOHxDAAGAliYg

Bernard wrote...

> > If the RADIUS server has to parse it, then complex attributes are
> > allowed for authentication and security...
>
> I think the question is why the exemption should be so broad.=A0 The
> security and authentication attributes described in Appendix B =
required
> computation.=A0 That is the RADIUS server had to add code in order to
> compare the authentication result presented by the RADIUS client with =
the
> result it calculated based on its own data.=20
>
> However, if the RADIUS server doesn't have to do any computation (e.g.
> if it is just sending security or authentication-related data to the
> RADIUS client), then there is no intrinsic reason why RADIUS server
> code needs to change.=A0 In that case, why should the exemption apply?

I don't think I ever saw an answer to this on the list.  Could we close =
out
this discussion, and perhaps craft some revised text, before the next =
draft
version is submitted?


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 13 Sep 2009 18:25:25 +0000
Message-ID: <4AAD38C8.9030408@deployingradius.com>
Date: Sun, 13 Sep 2009 20:24:08 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: RADEXT Virtual Interim Agenda - Take One
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> RADEXT WG Virtual Interim Agenda

  On a related note, how many people plan on being at the next IETF?

  I'm not sure yet if I will be able to make it.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 12 Sep 2009 20:14:18 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_eec3214d-b35d-4623-92f3-b729d44cd4f1_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT Virtual Interim Agenda - Take One
Date: Sat, 12 Sep 2009 13:13:48 -0700
MIME-Version: 1.0

--_eec3214d-b35d-4623-92f3-b729d44cd4f1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba 
David Nelson 

Tuesday=2C October 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:00 EDT)


8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
   Document Status=20

Documents completing IETF Last Call (20 minutes)

8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documents Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server

9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work Items (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls




--_eec3214d-b35d-4623-92f3-b729d44cd4f1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







RADEXT WG Virtual Interim Agenda

Chairs: Bernard Aboba <=3Bbe=
rnard_aboba@hotmail.com>=3B
David Nelson <=3Bd.b.nelson@comcast.net&=
gt=3B

Tuesday=2C October 13=2C 2009
8 AM - 10 AM PDT (11:00 - 13:=
00 EDT)


8:00 AM - 8:20 AM  Preliminaries
   Jabber scribe
=
   Document Status 

Documents completing IETF Last Call (20 minutes)=


8:20 AM - 8:40 AM Design Guidelines document=2C Alan DeKok (20  min=
utes)
http://tools.ietf.org/html/draft-ietf-radext-design

Documen=
ts Completing WG Last Call (20 minutes)

8:40 AM - 8:50 AM RADSEC=2C =
Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-=
radsec

8:50 AM - 9:00 AM Status-Server document=2C Alan DeKok (10 mi=
nutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server
9:00 AM - 9:10 AM RADIUS over TCP document=2C Alan DeKok (10 minutes)
h=
ttp://tools.ietf.org/html/draft-ietf-radext-tcp-transport

WG Work It=
ems (20 minutes)

9:10 AM - 9:20 AM NAI-based Peer Discovery=2C Stefa=
n Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynam=
ic-discovery

9:20 AM - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 mi=
nutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls


=

<=
span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=
=2C 85)=3B text-decoration: underline=3B">

=

--_eec3214d-b35d-4623-92f3-b729d44cd4f1_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sat, 12 Sep 2009 19:55:08 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_eef42904-7302-4c5b-9a39-40ee19fd8f02_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG Virtual Interim Meeting October 13, 2009
Date: Sat, 12 Sep 2009 12:53:55 -0700
MIME-Version: 1.0

--_eef42904-7302-4c5b-9a39-40ee19fd8f02_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADEXT WG will be having a Virtual Interim Meeting on Tuesday=2C Octobe=
r 13=2C 2009 from 8:00 AM - 10:00 AM PDT. =20

Details on the agenda and conference calling parameters for the meeting wil=
l be available here:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt





--_eef42904-7302-4c5b-9a39-40ee19fd8f02_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






The RADEXT WG will be having a Virtual Interim Meeting on Tuesday=2C Octobe=
r 13=2C 2009 from 8:00 AM - 10:00 AM PDT. =3B 

Details on the ag=
enda and conference calling parameters for the meeting will be available he=
re:
http://www.drizzle.com/~aboba/RADEXT/oct-virtual-interim.txt

=




=

--_eef42904-7302-4c5b-9a39-40ee19fd8f02_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 10 Sep 2009 14:16:33 +0000
Message-ID: <4AA90A0A.7020404@deployingradius.com>
Date: Thu, 10 Sep 2009 16:15:38 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Jari Arkko 
CC: Alper Yegin ,  "'Romascanu, Dan \(Dan\)'" , bernarda@microsoft.com, mbeadles@endforce.com, pasi.eronen@nokia.com,  rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jari Arkko wrote:
> Section 1.2 boilerplate is not according to RFC 2119.

  Fixed.

> grammer => grammar

  Fixed.

>> o Section 2.1 did not contain ABNF for the UTF-8 form of the  
>>             realm. This makes it impossible to create an
>> inter-operable               internationalized version of the realm
> 
> But the realm was not specified to carry UTF-8. As the RFC said later:
...
> I realize that there may be other reasons -- such as compatibility with
> EAP RFCs that demands plain UTF-8 should be used. However, the argument
> above does not seem correct.

  The later text discusses this, and could be merged:

o The requirement in Section 2.1 that realms are ASCII conflicts
  with the Extensible Authentication Protocol (EAP) and RADIUS, which
  are both 8-bit clean, and which both recommend the use of UTF-8 for
  identities.

>> o Section 2.5 required mappings that are language-specific,  
>>             and which are nearly impossible to perform correctly
>> without               information about that language.
> 
> I guess this means Section 2.4 of RFC 4282, right?

  Yes.

> Also, the mappings required in that section are to be done by the end
> systems where the user types in the strings. Such end systems can be
> aware of what character set and language the user employs. I agree that
> none of the intermediate systems could have any idea about that, but
> AFAICT that was not required by the RFC.

  The suggestion was for proxies to perform normalized comparisons,
which requires the mappings.

  The update suggests (essentially) using "strcmp" for comparisons.

  That could say instead:

o Section 2.4 required mappings that are language-specific,
  and which are nearly impossible for intermediate nodes to perform
  correctly without information about that language.

>>  normalization form NFC for NAIs is REQUIRED.
> Expand NFC

  Done.

>> The grammar for       the username is based on [RFC0821], and the
>> grammar for the realm is        the user and realm portion is based on
>> a combination of the "nai"       an updated version of
>> [RFC1035].        defined in [RFC4282] Section 2.1, and the
>> "utf8-addr-spec" defined in               [RFC5335] Section 4.4.
> I was confused by this statement. Do you mean that you normatively refer
> 4282 for these definitions or that this is how you arrived at the ABNF?

  It means how I arrived at the ABNF.

> I think you should just say "this is the ABNF" and if there's any
> rationale that needs to be said, add it to Section 1.4.

  Ok.  It looked awkward to add it to 1.4, so I added it to the appendix.

>> .fi
> 
> Nroff problem...

  Fixed.

>> in question. Therefore, the username portion SHOULD be treated as
> 
> Since you changed the ABNF names, this probably should now be
> utf8-username to be exact what you mean by the username portion.

  Fixed.

>> In order to ensure a canonical representation
> 
> I would like to understand this better. 4282 provided canonicalization
> in order to make sure that when you look up a username db lookups and
> routing table comparisons work. Does the bis have the same property, and
> how so?

  We can say:

The form suggested in [RFC4282] depended on
intermediate nodes performing canonicalizations based on insufficient
information, which meant that the form was not canonical.  This
document instead suggests (Section 2.10) that the realm owner provide
a canonical form of the realm, and that all intermediate nodes use
that form without modification.

  This means that there is only one canonical form: that supplied by the
realm owner.

>>    In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
>>    systems to perform NAI comparisons, matching, and AAA routing based
>>    on the NAI as it is received.  This requirement provides a canonical
>>    representation, ensures that intermediate systems such as AAA proxies
>>    do not need to perform translations, and can be expected to work
>>    through systems that are unaware of international character sets.
> 
> I though that this was the case already with RFC 4282, but maybe I'm
> missing something.

  See the above comment.  The *intent* in 4282 was to provide a
canonical representation.  Unfortunately, it cannot be used to provide that.

>> For example, much of the common realm routing can be done on the  
>>             "utf8-realm" portion of NAI, through simple checks for
>> equality.
> 
> I thought that suffix match was also a possibility in some systems.

  A *partial* suffix match?  (e.g. foo.example.com matches example.com)

  That's possible, but fairly rare.

>> There are, however, a number of problems with this approach. A AAA  
>>             proxy may not have sufficient information in order to
>> perform the               ToAscii conversion properly. ...

> And here's the tradeoff for using UTF-8 as opposed to IDN unaware name
> slots. I was trying to think about situations where the DNS lookups are
> needed and whether they'd form a problem. Can you name a few of the
> situations where DNS name lookups from NAIs are actually used today?

  Diameter.  RadSec (RADIUS over SSL over TCP), which is being
standardized right now.

  It's pretty rare, which means we should get it right before we have
wide-spread deployments.

  I'm not aware of any scenario where AAA servers would use arbitrary
strings supplied by the user to do DNS lookups, or why anyone would
think that this is a good idea.

  It would be MUCH better to have a AAA routing protocol, where "home"
servers could propagate realm / punycode data to proxies.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 10 Sep 2009 09:08:48 +0000
From: "Glen Zorn" 
To: "'Jari Arkko'" 
Cc: , "Paul Hoffman" , "Harald Tveit Alvestrand" 
Subject: RE: [Technical Errata Reported] RFC4282 (1850)
Date: Thu, 10 Sep 2009 11:07:18 +0200
Message-ID: <000001ca31f6$264396c0$72cac440$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoxddlL2UqxC0XlQH2l0xRSN5oA7gAdDGeg
Content-Language: en-us

Jari Arkko [mailto:jari.arkko@piuha.net] writes:

> Glen Zorn wrote:
> > I thought about writing a long response to this, referencing RFCs
> 3454 &
> > 4013 and the Unicode 3.2 standard but in the end decided that the use
> of
> > logic and analysis would be a total waste of time.  So I'll just say
> that
> > this Errata makes no sense at all & let it go at that.  To understand
> why
> > it's nonsense, you'll have to do your own research.
> >
> >
> 
> Humor me

If you insist...

> Apparently I don't understand i18n as well as the rest of you do :-)

I absolutely not an expert on internationalization (though I confess to
having conversed occasionally with Paul Hoffman & Harald Alvestrand, who are
veritable founts of knowledge on the subject -- hopefully if I get any of
this wrong one of them can save us from my ignorance): the last work I did
on it was for L2TPv3 more than 4 years ago.  Fortunately, however, no such
expertise is really needed, aside from the abilities to read and reason.
The reference in the original text to which the erratum refers is to section
2.5 of RFC 4013, but that just points to Appendix A.1 of RFC 3454.  Appendix
A.1 is just a list of the unassigned code points in Unicode 3.2.  There is
no mechanism specified in 3454 for assigning code points (via IANA, for
example); that's because code points are assigned in the Unicode standard.
That should be enough: the list of unassigned code points is in an RFC
which, by definition, will never change.  If, however, one possessed a
little bit of knowledge about Unicode (say, from spending 20-30 minutes
looking around http://www.unicode.org) one could discover that the assigned
and unassigned code points are part of the Unicode repertoire for a given
major or minor version of the standard.  This means that section A.1 of RFC
3454 defines forever the set of unassigned code points: unassigned code
points may be assigned but not in v3.2.  I hope it's clear from this
discussion that talking about "unassigned code points" w/o reference to a
stringprep profile or Unicode version is meaningless.  The "old text" was
correct and precise, including a stable reference to a well-defined set of
code points; the proposed replacement text is, quite literally, nonsense.

> 
> Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 17:45:35 +0000
From: "Glen Zorn" 
To: , , , , , , , 
Cc: , 
Subject: RE: [Technical Errata Reported] RFC4282 (1850)
Date: Wed, 9 Sep 2009 19:44:07 +0200
Message-ID: <004501ca3175$387ea900$a97bfb00$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcowmzYlv1u8ZfpHQiG//1rrlLOUhAA2Nh3w
Content-Language: en-us

I thought about writing a long response to this, referencing RFCs 3454 &
4013 and the Unicode 3.2 standard but in the end decided that the use of
logic and analysis would be a total waste of time.  So I'll just say that
this Errata makes no sense at all & let it go at that.  To understand why
it's nonsense, you'll have to do your own research.

> The following errata report has been submitted for RFC4282,
> "The Network Access Identifier".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1850
> 
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok 
> 
> Section: 2.4
> 
> Original Text
> -------------
>    o  Unassigned code points are specified in Section 2.5 of [RFC4013].
>       The use of unassigned code points is prohibited.
> 
> Corrected Text
> --------------
>   o Unassigned code points MUST be ignored
> 
> Notes
> -----
> Unassigned code points sometimes go through a process called
> "assignment".  This means that they suddenly become valid.
> 
> Implementations that forbid unassigned code points will not be updated
> when the standards change to assign them.  Therefore, they should
> ignore unassigned code points.
> 
> Happily, this is what all implementations do.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC4282 (draft-ietf-radext-rfc2486bis-06)
> --------------------------------------
> Title               : The Network Access Identifier
> Publication Date    : December 2005
> Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
> Category            : PROPOSED STANDARD
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 17:02:17 +0000
Message-ID: <4AA7DF81.2010609@piuha.net>
Date: Wed, 09 Sep 2009 20:01:53 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: aland@freeradius.org
CC: Alper Yegin ,  'Glen Zorn' , "'Romascanu, Dan \(Dan\)'" , bernarda@microsoft.com,  mbeadles@endforce.com, pasi.eronen@nokia.com, rbonica@juniper.net,  d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks again for writing this up.

Some initial comments:

Overall I liked it, but there are of course of number of things to 
discuss...

Section 1.2 boilerplate is not according to RFC 2119.

grammer => grammar

> o Section 2.1 did not contain ABNF for the UTF-8 form of the   
>             realm. This makes it impossible to create an 
> inter-operable   
>             internationalized version of the realm

But the realm was not specified to carry UTF-8. As the RFC said later:

   The realm name is an "IDN-unaware domain name slot" as defined in
   [RFC3490].  That is, it can contain only ASCII characters.  An
   implementation MAY support Internationalized Domain Names (IDNs)
   using the ToASCII operation; see [RFC3490] for more information.

I realize that there may be other reasons -- such as compatibility with 
EAP RFCs that demands plain UTF-8 should be used. However, the argument 
above does not seem correct.

> o Section 2.5 required mappings that are language-specific,   
>             and which are nearly impossible to perform correctly 
> without   
>             information about that language.

I guess this means Section 2.4 of RFC 4282, right?

Also, the mappings required in that section are to be done by the end 
systems where the user types in the strings. Such end systems can be 
aware of what character set and language the user employs. I agree that 
none of the intermediate systems could have any idea about that, but 
AFAICT that was not required by the RFC.

>  normalization form NFC for NAIs is REQUIRED.
Expand NFC

> The grammar for   
>     the username is based on [RFC0821], and the grammar for the realm 
> is        the user and realm portion is based on a combination of the 
> "nai"   
>     an updated version of [RFC1035].        defined in [RFC4282] 
> Section 2.1, and the "utf8-addr-spec" defined in   
>             [RFC5335] Section 4.4.
I was confused by this statement. Do you mean that you normatively refer 
4282 for these definitions or that this is how you arrived at the ABNF? 
I think you should just say "this is the ABNF" and if there's any 
rationale that needs to be said, add it to Section 1.4.

> .fi

Nroff problem...

> in question. Therefore, the username portion SHOULD be treated as

Since you changed the ABNF names, this probably should now be 
utf8-username to be exact what you mean by the username portion.

> In order to ensure a canonical representation

I would like to understand this better. 4282 provided canonicalization 
in order to make sure that when you look up a username db lookups and 
routing table comparisons work. Does the bis have the same property, and 
how so?

>    In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
>    systems to perform NAI comparisons, matching, and AAA routing based
>    on the NAI as it is received.  This requirement provides a canonical
>    representation, ensures that intermediate systems such as AAA proxies
>    do not need to perform translations, and can be expected to work
>    through systems that are unaware of international character sets.

I though that this was the case already with RFC 4282, but maybe I'm 
missing something.

> For example, much of the common realm routing can be done on the   
>             "utf8-realm" portion of NAI, through simple checks for 
> equality.

I thought that suffix match was also a possibility in some systems.

> 2.7. Routing inside of AAA Systems
Good stuff.

> There are, however, a number of problems with this approach. A AAA   
>             proxy may not have sufficient information in order to 
> perform the   
>             ToAscii conversion properly. We therefore RECOMMEND that 
> only the   
>             owner of the realm perform the ToAscii conversion. We 
> RECOMMEND that   
>             the owner of the realm pre-provision to all proxies the 
> "utf8-realm"   
>             portion of the NAI, along with the canonical form returned 
> by the   
>             ToAscii function. This canonical form can then be used in 
> the   
>             logical AAA routing table discussed above, in order to 
> perform DNS   
>             lookups

And here's the tradeoff for using UTF-8 as opposed to IDN unaware name 
slots. I was trying to think about situations where the DNS lookups are 
needed and whether they'd form a problem. Can you name a few of the 
situations where DNS name lookups from NAIs are actually used today?

> 2.10.1. Historical Practices
I'm personally not very fond of the decoration practices, but they do 
exist. I think we need a discussion before those can be removed from the 
RFC.

Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 16:19:41 +0000
Message-ID: <4AA7D564.6050803@piuha.net>
Date: Wed, 09 Sep 2009 19:18:44 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: aland@freeradius.org
CC: Glen Zorn ,  "'Romascanu, Dan \(Dan\)'" , bernarda@microsoft.com, mbeadles@endforce.com, pasi.eronen@nokia.com,  rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Excellent -- I will review this. For the benefit of others, here's a diff:

http://tools.ietf.org/rfcdiff?url1=rfc4282.txt&url2=draft-dekok-radext-nai-00.txt

(and to the original RFC: 
http://tools.ietf.org/rfcdiff?url1=rfc2486.txt&url2=draft-dekok-radext-nai-00.txt)

Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 14:02:47 +0000
From: "Alper Yegin" 
To: "'Glen Zorn'" , "'Jari Arkko'" 
Cc: , "'Romascanu, Dan \(Dan\)'" , , , , , , , 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 17:01:30 +0300
Message-ID: <005a01ca3156$12d7c700$38875500$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoxUQwvQ2aZ1ncAQGyo+KH/DoDNjQAAwtlQAABvE1A=
Content-Language: en-us

> You're absolutely right; I was thinking of RFC 2486, which it obsolete.
> The
> point remains the same, however: changes to 4282 don't just effect
> RADIUS,
> but Diameter, possibly EAP and 

+ Mobile IP family of protocols....


> a number of standards published by other
> SDOs.

Indeed.

What is the take on backward compatibility?

Alper





> 
> >
> > In any case, I would suggest we stop talking about process or other
> non
> > essential stuff. If the 4282 i18n text is not correct, is there some
> > other text that would work, Alan?
> >
> > Jari
> 
> 
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 13:52:23 +0000
From: "Glen Zorn" 
To: "'Jari Arkko'" 
Cc: , "'Romascanu, Dan \(Dan\)'" , , , , , , , 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 15:51:26 +0200
Message-ID: <006601ca3154$b2cd66e0$186834a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoxUQwvQ2aZ1ncAQGyo+KH/DoDNjQAAwtlQ
Content-Language: en-us

Jari Arkko [mailto:jari.arkko@piuha.net] writes:

> Glen,
> 
> > Why not?  My understanding is that accepted technical errata are
> generally
> > saved up & incorporated in a new RFC.  Is that incorrect?  If not,
> why isn't
> > that the way to deal with this particular case?
> >
> 
> Erratas are for correcting small problems. If you have to rewrite large
> parts, that requires significant effort, review, and a proper new
> document.
> 
> > Since 4282 wasn't the product of either the radext or radius WGs,
> what makes
> > radext the right place to do it?  I'd suggest a new WG, with Alan
> DeKok as a
> > Chair.
> >
> 4282 was a product of the RADEXT WG.

You're absolutely right; I was thinking of RFC 2486, which it obsolete.  The
point remains the same, however: changes to 4282 don't just effect RADIUS,
but Diameter, possibly EAP and a number of standards published by other
SDOs.

> 
> In any case, I would suggest we stop talking about process or other non
> essential stuff. If the 4282 i18n text is not correct, is there some
> other text that would work, Alan?
> 
> Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 13:25:53 +0000
Message-ID: <4AA7ACD4.8010204@piuha.net>
Date: Wed, 09 Sep 2009 16:25:40 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Glen Zorn 
CC: aland@freeradius.org, "'Romascanu, Dan \(Dan\)'" ,  bernarda@microsoft.com, mbeadles@endforce.com, pasi.eronen@nokia.com,  rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com,  radiusext@ops.ietf.org
Subject: Re: [Technical Errata Reported] RFC4282 (1848)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Glen,

> Why not?  My understanding is that accepted technical errata are generally
> saved up & incorporated in a new RFC.  Is that incorrect?  If not, why isn't
> that the way to deal with this particular case?
>   

Erratas are for correcting small problems. If you have to rewrite large 
parts, that requires significant effort, review, and a proper new document.

> Since 4282 wasn't the product of either the radext or radius WGs, what makes
> radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
> Chair.
>   
4282 was a product of the RADEXT WG.

In any case, I would suggest we stop talking about process or other non 
essential stuff. If the 4282 i18n text is not correct, is there some 
other text that would work, Alan?

Jari


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 13:23:54 +0000
From: "Glen Zorn" 
To: 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , , 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 15:22:56 +0200
Message-ID: <005c01ca3150$b6e89140$24b9b3c0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoxT21V4jOsQe+ITM+/iKEIe1rJdwAAMofQ
Content-Language: en-us

Alan T DeKok [mailto:aland@freeradius.org] writes:

> Glen Zorn wrote:
> > I count 8 sentences (including the one reproduced from the RFC), not
> 20.
> 
>   Please check your inbox.  There were other errata filed at the same
> time, with additional explanatory text.

I didn't respond to those.  How are they relevant?

> 
> > One of those sentences appears to be irrelevant hyperbole ("Much of
> RFC 4282
> > is simply wrong.") & another is incomprehensible (what does
> "Normalization
> > can be done only when both the local and character set information is
> > included with the text." mean?  Did you mean "locale"?  Why should we
> have
> > to guess?).  Based upon this evidence, I have no choice but to
> conclude that
> > you are absolutely right: RFC 4282 should be trashed immediately
> (apparently
> > the same conclusion reached by the IESG, based upon the same
> evidence).
> 
>   As I said, please check the RADEXT archives for longer discussions
> about this issue.  That discussion includes comments from other people
> explaining what is wrong with 4282.

Alan, you filed an Errata with the RFC Editor.  Do you expect them to search
the radext archives?

> 
>   Maybe one of those people can talk to you without you claiming that
> they have a god complex.  I know I can't.

For DeKok's sake, quit your whining! ;-)

> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 13:01:03 +0000
From: "Glen Zorn" 
To: "'Jari Arkko'" , 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 14:59:57 +0200
Message-ID: <004701ca314d$8a927fa0$9fb77ee0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoxSFXHiXKy+/+MRyK5Kp6mbwzlywABGREA
Content-Language: en-us

Jari Arkko [mailto:jari.arkko@ericsson.com] writes:

> Alan,
> 
> >   It would be good to note at least that the document should be
> largely
> > ignored.  Errata may be a good way to do this.
> >
> 
> I do not believe errata is the right way to do this. 

Why not?  My understanding is that accepted technical errata are generally
saved up & incorporated in a new RFC.  Is that incorrect?  If not, why isn't
that the way to deal with this particular case?

> Furthermore, 4282
> contains more updates than the i18n parts.
> 
> >   There was some discussion last year about working on an update to
> > 4282.  There didn't seem to be much interest, unfortunately.  Maybe
> if
> > we can get the 4-5 pending RADEXT documents out of the way, there may
> be
> > interest in working on updates to 4282.
> >
> 
> That is the best way, IMO. 

Since 4282 wasn't the product of either the radext or radius WGs, what makes
radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
Chair.

> We also need to analyze the problem and
> possible solutions in detail. I confess that I have not looked at the
> issues, so I can offer no comment on them yet.
> 
> Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 12:55:41 +0000
From: "Glen Zorn" 
To: 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , , 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 14:54:18 +0200
Message-ID: <004001ca314c$b85c4250$2914c6f0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoxRqBHLbN/CTa0TQiwrtyXTPaPNgAA9f7A
Content-Language: en-us

Alan T DeKok [mailto:aland@freeradius.org] writes:

> Glen Zorn wrote:
> > "it's wrong" hardly qualifies as "pointing out the problems".  OTOH,
> this
> > message (was it so hard?) may.
> 
>   The errata I filed had explanations as to what was wrong, why it was
> wrong, and suggested replacement text.
> 
>   You picked *one* sentence out of 20, ignored the rest, ignored the
> previous mailing list discussion, and then claimed (essentially) that I
> had no justification for seeing problems with 4282.
> 
>   Could you please read my messages before attacking me?

Terribly unfair of me.  To redress this wrong, I have reproduced the erratum
in question in full below:

Errata ID: 1848

Status: Reported
Type: Technical

Reported By: Alan DeKok
Date Reported: 2009-09-08


Section 2.4 says: 

   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

It should say:

  o Normalization is, in general, a bad idea.
Notes:

Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set
information is included with the text. And that information is not included
with the username or realm.

In addition, not all systems will treat "User" the same as "user". The
decision about how to
compare user names is site specific. User name comparisons SHOULD NOT be
performed on
any system other than the final one that performs user authentication. 


I count 8 sentences (including the one reproduced from the RFC), not 20.
One of those sentences appears to be irrelevant hyperbole ("Much of RFC 4282
is simply wrong.") & another is incomprehensible (what does "Normalization
can be done only when both the local and character set information is
included with the text." mean?  Did you mean "locale"?  Why should we have
to guess?).  Based upon this evidence, I have no choice but to conclude that
you are absolutely right: RFC 4282 should be trashed immediately (apparently
the same conclusion reached by the IESG, based upon the same evidence).

> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 10:25:46 +0000
From: "Glen Zorn" 
To: 
Cc: "'Romascanu, Dan \(Dan\)'" , , , , , , , , 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 12:24:15 +0200
Message-ID: <002401ca3137$c375a5b0$4a60f110$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoxM2AqslUD/MQeRDu0aUO3Fbb8iQAA+ZkQ
Content-Language: en-us

Alan T DeKok [mailto:aland@freeradius.org] writes:

> Glen Zorn wrote:
> > Not that I want to question (God forbid!) the godlike opinion of Alan
> DeKok,
> > but could we have just a smidgeon of justification for that statement
> before
> > tossing RFC 4282?
> 
>   Perhaps you would appreciate my comments more if I noted that:
> 
> a) the i18n work in 4282 has been deprecated, found to be faulty, or
>    replaced, by later i18n documents
> 
> b) nearly all of the rest of the recommendations in 4282 have been
>    ignored (and not implemented) by all of the AAA vendors
> 
> c) I was not involved in any of the i18n work that negated the
>    recommendations of 4282
> 
> d) no major AAA vendor has ever asked for my opinion on how to
>    implement 4282 in their product.
> 
> 
>   Don't blame the messenger.
> 
>   If you have a problem with the statement that 4282 is wrong, go fight
> with the i18n people.  Once you've done that, go force all of the AAA
> vendors to implement the other recommendations of 4282.
> 
>   Or, you can attack me for pointing out the problems.  Which is
> easier?

"it's wrong" hardly qualifies as "pointing out the problems".  OTOH, this
message (was it so hard?) may.

> 
> 
>   This subject was discussed last year on the on RADEXT list.  See
> message subjects with 4282 in them.  I don't see you having any
> comments
> at that time.  I also see a number of comments from other people who
> also claim to see problems with 4282.
> 
> 
>   At a minimum:
> 
> - the mapping requirements are likely wrong.  Intermediate nodes
>   should not be doing comparisons on the username portion of an NAI.
> 
> - the bidirectional rules are superseded by later BIDI documents
> 
> - the suggestion to reject NAIs with unassigned code points
>   means that those code points can never be assigned, as conformant
>   implementations that have not yet been updated will reject those
> NAIs.
> 
> - the suggestion to encode NAIs as punycode is implemented by no one.
> 
> - the suggest for intermediate nodes to normalize the NAI is
>   unnecessary, can cause inter-operability requirements, and is
>   implemented by no one.
> 
> 
>   Again, these are not *my* points.  I'm just repeating comments from
> *other* people on the RADEXT mailing list.
> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 09:31:37 +0000
From: "Glen Zorn" 
To: "'Romascanu, Dan \(Dan\)'" , , , , , , , 
Cc: , 
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 11:29:59 +0200
Message-ID: <001501ca3130$371b7ce0$a55276a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcowmiKV2b2xb7C7RyaLek8HYvzrNwAjlsqgAAGzD7A=
Content-Language: en-us

Dan Romascanu [mailto://dromasca@avaya.com] writes:

> > Much of RFC 4282 is simply wrong.
> 
> If this is the case, I do not believe that an Errata is the right
> instrument to fix the situation, but rather the WG working on a
> document
> to obsolete and replace RFC 4282 or simply declare it Historical.
> 
> I would invite other opinions from the WG and especially from the
> editors.

Not that I want to question (God forbid!) the godlike opinion of Alan DeKok,
but could we have just a smidgeon of justification for that statement before
tossing RFC 4282?

...


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 08:41:20 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Technical Errata Reported] RFC4282 (1848)
Date: Wed, 9 Sep 2009 10:40:24 +0200
Message-ID: 
Thread-Topic: [Technical Errata Reported] RFC4282 (1848)
thread-index: AcowmiKV2b2xb7C7RyaLek8HYvzrNwAjlsqg
From: "Romascanu, Dan (Dan)" 
To: "RFC Errata System" , , , , , , , 
Cc: , 

> Much of RFC 4282 is simply wrong.=20

If this is the case, I do not believe that an Errata is the right
instrument to fix the situation, but rather the WG working on a document
to obsolete and replace RFC 4282 or simply declare it Historical.=20

I would invite other opinions from the WG and especially from the
editors.=20

Thanks and Regards,

Dan


> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20
> Sent: Tuesday, September 08, 2009 6:35 PM
> To: bernarda@microsoft.com; mbeadles@endforce.com;=20
> jari.arkko@ericsson.com; pasi.eronen@nokia.com; Romascanu,=20
> Dan (Dan); rbonica@juniper.net; d.b.nelson@comcast.net;=20
> Bernard_Aboba@hotmail.com
> Cc: aland@freeradius.org; radiusext@ops.ietf.org;=20
> rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC4282 (1848)
>=20
>=20
> The following errata report has been submitted for RFC4282,=20
> "The Network Access Identifier".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4282&eid=3D1848
>=20
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok 
>=20
> Section: 2.4
>=20
> Original Text
> -------------
>    o  Normalization requirements, as specified in Section 2.2 of
>       [RFC4013], are also designed to assist in comparisons.
>=20
> Corrected Text
> --------------
>   o Normalization is, in general, a bad idea.
>=20
> Notes
> -----
> Much of RFC 4282 is simply wrong.
>=20
> Normalization can be done only when both the local and=20
> character set information is included with the text.  And=20
> that information is not included with the username or realm.
>=20
> In addition, not all systems will treat "User" the same as=20
> "user".  The decision about how to compare user names is site=20
> specific.  User name comparisons SHOULD NOT be performed on=20
> any system other than the final one that performs user authentication.
>=20
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,=20
> please use "Reply All" to discuss whether it should be=20
> verified or rejected. When a decision is reached, the=20
> verifying party (IESG) can log in to change the status and=20
> edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC4282 (draft-ietf-radext-rfc2486bis-06)
> --------------------------------------
> Title               : The Network Access Identifier
> Publication Date    : December 2005
> Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
> Category            : PROPOSED STANDARD
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 09 Sep 2009 07:55:55 +0000
Message-ID: <4AA75F45.6050302@deployingradius.com>
Date: Wed, 09 Sep 2009 09:54:45 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Stig Venaas 
CC: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stig Venaas wrote:
> I'm a bit confused by that first sentence. The TCP session might be
> reset without the watchdog marking it down. Wouldn't that be sufficient
> to say that the connection is down?

  Yes.

> 2. Should the term RadSec be replaced with RADIUS over TLS?

  Yes.  The decision to remove the RadSec name was made after the draft
had been submitted.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 20:38:37 +0000
Message-ID: <4AA6C0B2.8040404@venaas.com>
Date: Tue, 08 Sep 2009 13:38:10 -0700
From: Stig Venaas 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> This is a reminder of the ongoing call for review of the document "DTLS 
> as a Transport Layer for RADIUS" for adoption as a RADEXT WG work item.  
> This document is being targeted at Experimental status.
>  
> The document is available for review here:
> http://tools.ietf.org/html/draft-dekok-radext-dtls
> 
> The original call for review expired August 7, 2009, but no comments 
> were received.  This call for input will last until October 2, 2009.  

I'm in favour of adoption,

Stig

> Please send email to the RADEXT WG mailing list indicating whether you 
> support adoption of this document as a RADEXT WG work item.  If you have 
> comments on the document, please also send these to the list in the 
> format described on the RADEXT WG Issues list:
> http://www.drizzle.com/~aboba/RADEXT/ 
> 
> 
> 
> 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 20:37:20 +0000
Message-ID: <4AA6C062.2000100@venaas.com>
Date: Tue, 08 Sep 2009 13:36:50 -0700
From: Stig Venaas 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "radiusext@ops.ietf.org" 
Subject: Re: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> This is a reminder of an ongoing RADEXT WG last call on "RADIUS over 
> TCP", prior to sending this document on to the IESG for publication as 
> an Experimental RFC.  The document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

Looks like my previous email didn't make it. I think the document is
ready, but two minor comments.

1. The draft says:

    RADIUS clients using RADIUS over TCP MUST NOT decide that a
    connection is down until the application layer watchdog algorithm has
    marked it DOWN ([RFC3539] Appendix A).  RADIUS clients using RADIUS
    over TCP MUST NOT decide that a RADIUS server is unresponsive until
    all TCP connections to it have been marked DOWN.

I'm a bit confused by that first sentence. The TCP session might be
reset without the watchdog marking it down. Wouldn't that be sufficient
to say that the connection is down?

2. Should the term RadSec be replaced with RADIUS over TLS?

Stig

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 20:37:03 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_"
From: Bernard Aboba 
To: Alan DeKok , "David B. Nelson" 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:36:16 -0700
MIME-Version: 1.0

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   If the RADIUS server has to parse it=2C then complex attributes are
> allowed for authentication and security...

I think the question is why the exemption should be so broad.  The security=
 and authentication attributes described in Appendix B required computation=
.  That is the RADIUS server had to add code in order to compare the authen=
tication result presented by the RADIUS client with the result it calculate=
d based on its own data.=20

However=2C if the RADIUS server doesn't have to do any computation (e.g. if=
 it is just sending security or authentication-related data to the RADIUS c=
lient)=2C then there is no intrinsic reason why RADIUS server code needs to=
 change.  In that case=2C why should the exemption apply? =20

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






>=3B   If the RADIUS server has to parse it=2C then complex attributes ar=
e
>=3B allowed for authentication and security...

I think the q=
uestion is why the exemption should be so broad. =3B The security and a=
uthentication attributes described in Appendix B required computation. =
=3B That is the RADIUS server had to add code in order to compare the authe=
ntication result presented by the RADIUS client with the result it calculat=
ed based on its own data. 

However=2C if the RADIUS server doesn't h=
ave to do any computation (e.g. if it is just sending security or authentic=
ation-related data to the RADIUS client)=2C then there is no intrinsic reas=
on why RADIUS server code needs to change. =3B In that case=2C why shou=
ld the exemption apply? =3B 

=

--_f23d86a1-b148-42d2-8d15-0d542bdc0c9e_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 20:13:01 +0000
Message-ID: <4AA6BA94.9020209@deployingradius.com>
Date: Tue, 08 Sep 2009 22:12:04 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: "David B. Nelson" 
CC: radiusext@ops.ietf.org
Subject: Re: Issue 313:  Security Exemption
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> I don't think that the "for purposes other than authentication or security?"
> text really addresses the inherent ambiguity.  My understanding is that the
> exemption is for authentication or security mechanisms internal to the
> RADIUS protocol.  The revised text does not make that "internal to RADIUS"
> limitation, and thus remains an open loop-hole, IMO.

  ?

   Does the attribute:

    * define a complex data type
    * that the RADIUS server and/or client will not treat as opaque data
      (see Section A.1.3)

  If the RADIUS server can treat it as opaque data, then it falls under
the purview of A.1.3.  It is permitted, independent of it being used for
authentication, security, or anything else.

  If the RADIUS server has to parse it, then complex attributes are
allowed for authentication and security...

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 18:18:35 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_"
From: Bernard Aboba 
To: "David B. Nelson" , Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 11:17:56 -0700
MIME-Version: 1.0

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> I agree.  My reading of the current=2C as well as that of others=2C howev=
er=2C is
> that *any* security related attribute=2C whether in support of the RADIUS
> protocol or some external entity=2C qualifies for an exemption to be desi=
gned
> as a complex type.  In that regard=2C "security" attributes for any usage=
 are
> covered by this exemption.

OK.  I would agree that this is too broad. =20

I think the idea was to exempt attributes where *computation* was required =
on the server and client (e.g. Digest Authentication=2C CHAP=2C etc.).   Bu=
t if there is no computation occurring=2C or if the attribute could be cons=
trued as opaque=2C I don't think the exemption is appropriate.=20

For example=2C consider a complex "Security Policy Attribute" sent from ser=
ver to client.  From the server point of view=2C there is no computation in=
volved=2C the server just sends the attribute to the client=2C who is expec=
ted to understand it.  In such a situation=2C there is no intrinsic reason =
why server code changes should be required.  Does such an attribute deserve=
 an exemption?  I would say no.=20

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







>=3B I agree.  My reading of the current=2C as well as that of others=
=2C however=2C is
>=3B that *any* security related attribute=2C whethe=
r in support of the RADIUS
>=3B protocol or some external entity=2C qu=
alifies for an exemption to be designed
>=3B as a complex type.  In th=
at regard=2C "security" attributes for any usage are
>=3B covered by t=
his exemption.

OK. =3B I would agree that this is too broad.&nbs=
p=3B 

I think the idea was to exempt attributes where *computation* =
was required on the server and client (e.g. Digest Authentication=2C CHAP=
=2C etc.). =3B =3B But if there is no computation occurring=2C or i=
f the attribute could be construed as opaque=2C I don't think the exemption=
 is appropriate. 

For example=2C consider a complex "Security Policy=
 Attribute" sent from server to client. =3B From the server point of vi=
ew=2C there is no computation involved=2C the server just sends the attribu=
te to the client=2C who is expected to understand it. =3B In such a sit=
uation=2C there is no intrinsic reason why server code changes should be re=
quired. =3B Does such an attribute deserve an exemption? =3B I woul=
d say no. 

=

--_b3dc1abb-bc82-450e-aeb0-524cf47bdf60_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 17:56:55 +0000
From: "David B. Nelson" 
To: "'Bernard Aboba'" , "'Alan DeKok'" 
Cc: 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:56:58 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <417999CAF9B9409F8F67091F96AF38FA@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcowrJxnTAlmj/pmRuOE2CMPMD6PEgAAHfUg

Bernard Aboba wrote...

> IMHO, if an attribute doesn't relate to RADIUS, but to
> some external entity, then it is effectively opaque and
> shouldn't be a complex attribute.

I agree.  My reading of the current, as well as that of others, however, is
that *any* security related attribute, whether in support of the RADIUS
protocol or some external entity, qualifies for an exemption to be designed
as a complex type.  In that regard, "security" attributes for any usage are
covered by this exemption.

> I think that's what Alan's suggested text says, more or less.

It seems to me be way toward the "less".  I think the applicability needs to
be clarified.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 17:48:59 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_313bde98-40bc-4051-b87d-180d21cb3a5f_"
From: Bernard Aboba 
To: "David B. Nelson" , Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 10:48:30 -0700
MIME-Version: 1.0

--_313bde98-40bc-4051-b87d-180d21cb3a5f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> I don't think that the "for purposes other than authentication or securit=
y?"
> text really addresses the inherent ambiguity.  My understanding is that t=
he
> exemption is for authentication or security mechanisms internal to the
> RADIUS protocol.  The revised text does not make that "internal to RADIUS=
"
> limitation=2C and thus remains an open loop-hole=2C IMO.

Appendix B talks about complex attributes.  I'm not sure which of these wou=
ld be considered "internal to RADIUS" and which would not be. =20

For example=2C is Digest Authentication (RFC 5090) internal to RADIUS?  Wha=
t about CHAP?  Or are we talking about Message-Authenticator? =20

IMHO=2C if an attribute doesn't relate to RADIUS=2C but to some external en=
tity=2C then it is effectively opaque and shouldn't be a complex attribute.=
  I think that's what Alan's suggested text says=2C more or less.=20

--_313bde98-40bc-4051-b87d-180d21cb3a5f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







>=3B I don't think that the "for purposes other than authentication o=
r security?"
>=3B text really addresses the inherent ambiguity.  My un=
derstanding is that the
>=3B exemption is for authentication or securi=
ty mechanisms internal to the
>=3B RADIUS protocol.  The revised text =
does not make that "internal to RADIUS"
>=3B limitation=2C and thus re=
mains an open loop-hole=2C IMO.

Appendix B talks about complex attri=
butes. =3B I'm not sure which of these would be considered "internal to=
 RADIUS" and which would not be. =3B 

For example=2C is Digest A=
uthentication (RFC 5090) internal to RADIUS? =3B What about CHAP? =
=3B Or are we talking about Message-Authenticator? =3B 

IMHO=2C =
if an attribute doesn't relate to RADIUS=2C but to some external entity=2C =
then it is effectively opaque and shouldn't be a complex attribute. =3B=
 I think that's what Alan's suggested text says=2C more or less. 

=

--_313bde98-40bc-4051-b87d-180d21cb3a5f_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 17:06:01 +0000
From: "David B. Nelson" 
To: "'Alan DeKok'" 
Cc: 
Subject: RE: Issue 313:  Security Exemption
Date: Tue, 8 Sep 2009 13:05:35 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <0645DE9E1086422EB82EDC431CE08A5D@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcosmghX1VPtkukgQc++FgVVO/oUfgEC9JYg

Sorry for the late response.  I'm still recuperating, and have not remained
on top of my IETF correspondence.

Alan DeKok wrote...

> >   RADIUS could transport parameters for *another* protocol.  Those
> > attributes are not security related.  They either follow the RADIUS data
> > model (int, IP address, etc.), or they are "opaque data" that RADIUS is
> > simply transporting on the behalf of the other protocol.
> 
>   Suggested text in Section A.2.2.:
> 
> A.2.2. Complex Data Types
> 
>    Does the attribute:
> 
>    * define a complex data type
>    * that the RADIUS server and/or client will not treat as opaque data
>      (see Section A.1.3)
>    * for purposes other than authentication or security?
> 
>    If the answers to all of the above items are "yes", this data type
>    SHOULD be replaced
>    with simpler types, as discussed above in Section A.2.1.  Also see
>    Section 2.1.3 for a discussion of why complex types are problematic.

I don't think that the "for purposes other than authentication or security?"
text really addresses the inherent ambiguity.  My understanding is that the
exemption is for authentication or security mechanisms internal to the
RADIUS protocol.  The revised text does not make that "internal to RADIUS"
limitation, and thus remains an open loop-hole, IMO.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:42:35 +0000
Date: Tue, 8 Sep 2009 08:38:52 -0700 (PDT)
Message-Id: <200909081538.n88Fcqfs027959@boreas.isi.edu>
To: bernarda@microsoft.com, mbeadles@endforce.com, jari.arkko@ericsson.com, pasi.eronen@nokia.com, dromasca@avaya.com, rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com
Subject: [Technical Errata Reported] RFC4282 (1850)
From: RFC Errata System 
Cc: aland@freeradius.org, radiusext@ops.ietf.org, rfc-editor@rfc-editor.org

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1850

--------------------------------------
Type: Technical
Reported by: Alan DeKok 

Section: 2.4

Original Text
-------------
   o  Unassigned code points are specified in Section 2.5 of [RFC4013].
      The use of unassigned code points is prohibited.

Corrected Text
--------------
  o Unassigned code points MUST be ignored

Notes
-----
Unassigned code points sometimes go through a process called "assignment".  This means that they suddenly become valid.

Implementations that forbid unassigned code points will not be updated when the standards change to assign them.  Therefore, they should ignore unassigned code points.

Happily, this is what all implementations do.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:38:45 +0000
Date: Tue, 8 Sep 2009 08:37:04 -0700 (PDT)
Message-Id: <200909081537.n88Fb41h027221@boreas.isi.edu>
To: bernarda@microsoft.com, mbeadles@endforce.com, jari.arkko@ericsson.com, pasi.eronen@nokia.com, dromasca@avaya.com, rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com
Subject: [Technical Errata Reported] RFC4282 (1849)
From: RFC Errata System 
Cc: aland@freeradius.org, radiusext@ops.ietf.org, rfc-editor@rfc-editor.org

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1849

--------------------------------------
Type: Technical
Reported by: Alan DeKok 

Section: 2.4

Original Text
-------------
   o  Bidirectional characters are handled as specified in Section 2.4
      of [RFC4013].

Corrected Text
--------------
  o Bidrectional characters are handled in a site-specific fashion

Notes
-----
The rules in [4013] have shortcomings.  Updates are in:

http://tools.ietf.org/html/draft-ietf-idnabis-bidi-05

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:37:22 +0000
Date: Tue, 8 Sep 2009 08:35:21 -0700 (PDT)
Message-Id: <200909081535.n88FZL4e026640@boreas.isi.edu>
To: bernarda@microsoft.com, mbeadles@endforce.com, jari.arkko@ericsson.com, pasi.eronen@nokia.com, dromasca@avaya.com, rbonica@juniper.net, d.b.nelson@comcast.net, Bernard_Aboba@hotmail.com
Subject: [Technical Errata Reported] RFC4282 (1848)
From: RFC Errata System 
Cc: aland@freeradius.org, radiusext@ops.ietf.org, rfc-editor@rfc-editor.org

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1848

--------------------------------------
Type: Technical
Reported by: Alan DeKok 

Section: 2.4

Original Text
-------------
   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

Corrected Text
--------------
  o Normalization is, in general, a bad idea.

Notes
-----
Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set information is included with the text.  And that information is not included with the username or realm.

In addition, not all systems will treat "User" the same as "user".  The decision about how to
compare user names is site specific.  User name comparisons SHOULD NOT be performed on
any system other than the final one that performs user authentication.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:17:44 +0000
Message-ID: <4AA6757F.7010402@deployingradius.com>
Date: Tue, 08 Sep 2009 17:17:19 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: RADIUS Errata #816 (RFC 4282)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  Could we not file an errata against 4282 saying  "This document is
nearly completely wrong: no one does what it recommends".

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:15:02 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADEXT WG mailing list issues
Date: Tue, 8 Sep 2009 08:14:34 -0700
MIME-Version: 1.0

--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










A number of you have sent me email noting that one or more of the following=
 problems:

a. Your posts are not making it to the list=2C when sent from a subscribed =
email address=3B
b. Your posts are not making it to the list=2C when sent from an unsubscrib=
ed email address=3B
c. You are not receiving posts sent to the list=3B

Based on my own experience and examination of the logs=2C the RADEXT WG lis=
t appears to have stopped functioning this weekend and messages sent to the=
 list during that time were not sent out.  The list is now functioning agai=
n=2C but the archive has remained down since September 2=2C 2009.

Be aware that the RADEXT WG list only allows subscribers to post=3B non-sub=
scriber emails are bounced. =20

If you have sent mail to the list that was not sent out=2C please resend it=
.=20



--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














A number of you have sent me email noting that one or more of the following=
 problems:

a. Your posts are not making it to the list=2C when sent =
from a subscribed email address=3B
b. Your posts are not making it to th=
e list=2C when sent from an unsubscribed email address=3B
c. You are not=
 receiving posts sent to the list=3B

Based on my own experience and =
examination of the logs=2C the RADEXT WG list appears to have stopped funct=
ioning this weekend and messages sent to the list during that time were not=
 sent out. =3B The list is now functioning again=2C but the archive has=
 remained down since September 2=2C 2009.

Be aware that the RADEXT W=
G list only allows subscribers to post=3B non-subscriber emails are bounced=
. =3B 

If you have sent mail to the list that was not sent out=
=2C please resend it. 

<=
tbody>


=

--_b2ed4fed-9e55-48c4-8feb-1ef75491bfb9_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:13:09 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #753 (RFC 4282)
Date: Tue, 8 Sep 2009 08:11:19 -0700
MIME-Version: 1.0

--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Anyone have an opinion on this one? As I recall=2C the use of 'FF' was inte=
ntional.=20


Status: Reported

Type: Technical



Reported By: Frank Ellermann

Date Reported: 2006-08-14



Section 2.1 says:


   c           =3D/ %x80-FF =3B UTF-8-Octet      allowed (not in RFC 2486)
                          =3B Where UTF-8-octet is any octet in the
                          =3B multi-octet UTF-8 representation of a
                          =3B unicode codepoint above %x7F.
                          =3B Note that c must also satisfy rules in
                          =3B Section 2.4=2C including=2C for instance=2C
                          =3B checking that no prohibited output is
                          =3B used (see also Section 2.3 of
                          =3B [RFC4013]).
   x           =3D  %x00-FF =3B all 128 ASCII characters=2C no exception=3B
                          =3B as well as all UTF-8-octets as defined
                          =3B above (this was not allowed in
                          =3B RFC 2486).  Note that x must nevertheless
                          =3B again satisfy the Section 2.4 rules.

It should say:

[see below]

Notes:


Shouldn't that be s/FF/F4/ as in STD 63=2C or maybe s/FF/FD/ ?







 EMAILING FOR THE GREATER GOOD
Join me=

--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















Anyone have an opinion on this one? As I recall=2C the use of 'FF' was inte=
ntional. 


Status: Reported

Type: Technical



Reported By: Frank Ellermann

Date Reported: 2006-08-14



Section 2.1 says:



   c           =3D/ %x80-FF =3B UTF-8-Octet      =
allowed (not in RFC 2486)
                          =3B Where UTF-8-octe=
t is any octet in the
                          =3B multi-octet UTF-8 re=
presentation of a
                          =3B unicode codepoint above =
%x7F.
                          =3B Note that c must also satisfy rules =
in
                          =3B Section 2.4=2C including=2C for instanc=
e=2C
                          =3B checking that no prohibited output is=

                          =3B used (see also Section 2.3 of
        =
                  =3B [RFC4013]).
   x           =3D  %x00-FF =3B all 12=
8 ASCII characters=2C no exception=3B
                          =3B as w=
ell as all UTF-8-octets as defined
                          =3B above (=
this was not allowed in
                          =3B RFC 2486).  Note t=
hat x must nevertheless
                          =3B again satisfy the =
Section 2.4 rules.

It should say:


[see below]

Notes:



Shouldn't that be s/FF/F4/ as in STD 63=2C or maybe s/FF/FD/ ?









3D"i'm" EMAILING FOR THE G=
REATER GOOD
Join me<=
/td>

=

--_9a3b4682-c4f7-498e-9ceb-bb4784186fe2_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:12:35 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_154e7599-aefa-4c44-b34b-e27990b1da86_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #757 (RFC 4282)
Date: Tue, 8 Sep 2009 08:10:55 -0700
MIME-Version: 1.0

--_154e7599-aefa-4c44-b34b-e27990b1da86_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










My recommendation is that this errata be accepted.=20
Status: Reported

Type: Technical



Reported By: Peter Koch

Date Reported: 2005-12-13



Section 2.6 says:


   The BNF of the realm portion allows the realm to begin with a digit=2C
   which is not permitted by the BNF described in [RFC1035].  This
   change was made to reflect current practice=3B although not permitted
   by the BNF described in [RFC1035]=2C Fully Qualified Domain Names
   (FQDNs) such as 3com.com are commonly used and accepted by current
   software.

It should say:

[not supplied]

Notes:


section 2.6 missed the update of the hostname syntax in

RFC 1123=2C section 2.1.



RFC 1123 (STD 3) 2.1 allows labels starting with a 

in fully qualified domain names of a host=2C RFC 1035 (STD 13)

2.3.1 still wants labels starting with a .





 EMAILING FOR THE GREATER GOOD
Join me=

--_154e7599-aefa-4c44-b34b-e27990b1da86_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














My recommendation is that this errata be accepted. 
Status: Re=
ported

Type: Technical



Reported By: Peter Koch

Date Reported: 2005-12-13



Section 2.6 says:



   The BNF of the realm portion allows the realm =
to begin with a digit=2C
   which is not permitted by the BNF described =
in [RFC1035].  This
   change was made to reflect current practice=3B al=
though not permitted
   by the BNF described in [RFC1035]=2C Fully Quali=
fied Domain Names
   (FQDNs) such as 3com.com are commonly used and acce=
pted by current
   software.

It should say:


[not supplied]

Notes:



section 2.6 missed the update of the hostname syntax in

RFC 1123=2C section 2.1.



RFC 1123 (STD 3) 2.1 allows labels starting with a <=3Bdigit>=3B

in fully qualified domain names of a host=2C RFC 1035 (STD 13)

2.3.1 still wants labels starting with a <=3Bletter>=3B.






=

3D"i'm" EMAILING FOR THE GREAT=
ER GOOD
Join me

=

--_154e7599-aefa-4c44-b34b-e27990b1da86_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:12:05 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #816 (RFC 4282)
Date: Tue, 8 Sep 2009 08:10:28 -0700
MIME-Version: 1.0

--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











My recommendation is that this errata be accepted "Pending Update".=20



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2005-12-18



=20

Unfortunately=2C the text of that RFC does not fully reflect the
established state of the IETF standards=2C by referring to obsolete
documents (e.g.=2C ex STD 10=2C RFC 821) and ignoring effective updates=2C
e.g.=2C STD 3=2C RFC 1123=2C and RFC 2821.

In particular=2C the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.

This is not true!
The pretended deviation in fact reflects the current standards.

The modification to RFC 952=2C RFC 821=2C et al. has already been
introduced into the IETF Standards by STD 3=2C RFC 1123 (Host
Requirements=2C Part II)=2C published 16 years ago=2C in October 1989.
Section 2.1 of that RFC=2C on page 13=2C says:

    "One aspect of host name syntax is hereby changed: the
     restriction on the first character is relaxed to allow
     either a letter or a digit. Host software MUST support
     this more liberal syntax."

and continues saying:

    "Host software MUST handle host names of up to 63 characters
     and SHOULD handle host names of up to 255 characters."

Therefore=2C it would have been strongly advisable to point out
on page 6 of RFC 4282=2C in Section 2.2=2C first bullet=2C that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO=2C it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs=2C AVPs=2C -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type=2C Length and Value fields=2C instead of just giving
the size of the Value (payload) field=3B the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !


Similarly=2C RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP=2C the only comparable protocol named in=20
RFC 4282 that is on the IETF Standards Track.

  o   L2F [RFC2341] has been published for information only
      as a Historic RFC 'ab initio'.

  o   PPTP [RFC2637] has purposely been rejected by the IETF --
      because of its well known significant security flaws=2C among
      other issues=2C and the Informational RFC 2637 has been
      published with a very clear IESG Note to this end.

I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols=2C in a manner that does not make clear the distinction.
The continued unreflected use of PPTP=2C in particular=2C is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet.  We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it=2C and push the evolved standards!



It should say:

[see above]

Notes:


from pending


--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















My recommendation is that this errata be accepted "Pending Update". 
=



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2005-12-18



 =3B


Unfortunately=2C the text of that RFC does not fu=
lly reflect the
established state of the IETF standards=2C by referring =
to obsolete
documents (e.g.=2C ex STD 10=2C RFC 821) and ignoring effect=
ive updates=2C
e.g.=2C STD 3=2C RFC 1123=2C and RFC 2821.

In part=
icular=2C the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasi=
zes making a deviation from established standards
for host / domain name=
s.

This is not true!
The pretended deviation in fact reflects the=
 current standards.

The modification to RFC 952=2C RFC 821=2C et al.=
 has already been
introduced into the IETF Standards by STD 3=2C RFC 112=
3 (Host
Requirements=2C Part II)=2C published 16 years ago=2C in October=
 1989.
Section 2.1 of that RFC=2C on page 13=2C says:

    "One as=
pect of host name syntax is hereby changed: the
     restriction on the =
first character is relaxed to allow
     either a letter or a digit. Hos=
t software MUST support
     this more liberal syntax."

and conti=
nues saying:

    "Host software MUST handle host names of up to 63 c=
haracters
     and SHOULD handle host names of up to 255 characters."
Therefore=2C it would have been strongly advisable to point out
on =
page 6 of RFC 4282=2C in Section 2.2=2C first bullet=2C that the
named r=
ules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!

Note: IMHO=2C it =
is a fundamental design flaw of RADIUS and certain
other protocols using=
 TLVs=2C AVPs=2C -- or however similar protocol
objects are named -- to =
specify that the 'length' information
(being stored in a single octet) i=
s to comprise the cumulative
size of the Type=2C Length and Value fields=
=2C instead of just giving
the size of the Value (payload) field=3B the =
latter solution would
always allow to fully exhaust the total range of a=
n 8-bit unsigned
Length and thereby allow payload octet strings of size =
0..255 !


Similarly=2C RFC 4282 ignores the standardization state=
 of the
proprietary historic tunnelling protocols that have served as'precursors with major deficiencies to learn from' for the
development =
of L2TP=2C the only comparable protocol named in 
RFC 4282 that is on th=
e IETF Standards Track.

  o   L2F [RFC2341] has been published for i=
nformation only
      as a Historic RFC 'ab initio'.

  o   PPTP [=
RFC2637] has purposely been rejected by the IETF --
      because of its=
 well known significant security flaws=2C among
      other issues=2C an=
d the Informational RFC 2637 has been
      published with a very clear =
IESG Note to this end.

I am surprised that a new Standards Track RFC=
 is getting published
that repeatedly refers to obsolete protocols equal=
ly as to official
protocols=2C in a manner that does not make clear the =
distinction.
The continued unreflected use of PPTP=2C in particular=2C i=
s seen by
major security consultants as 'one of the most widespread troj=
an
horses' in the current Internet.  We should do everything to
commu=
nicate and emphasize the 1998/1999 decisions of the IETF and
IESG and th=
e reasons behind it=2C and push the evolved standards!



It should say:


[see above]

Notes:



from pending

=

=


=

--_c2d5ad3e-1fb1-452e-8b2b-60b5bd1d3d42_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:11:35 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_ffb47776-6c14-4d11-a073-92c4bb88ac6b_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #1326 (RFC 5090)
Date: Tue, 8 Sep 2009 08:10:02 -0700
MIME-Version: 1.0

--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Errata ID: 1326


My recommendation is that this errata be accepted "Pending Update".=20



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2008-02-17



Throughout the document=2C when it says:


a)       header

b)       headers

c)       Header

It should say:

a)       header field

b)       header fields

c)       Header Field

Notes:


As a Standards Track document=2C RFC 5090 should use established

IETF standard terminology=2C and not fall back to common sluggish

and confusing terminology.  Concise Ref.:  RFC 4249=2C Section 3.1.1.



There are 24 instances of case a) throughout the RFC=3B

only Section 3.20 makes proper use of the IETF standard

terminology=3B case b) occurs twice in the RFC=3B

case c) applies to the title of Section 2.1.3.







 EMAILING FOR THE GREATER GOOD
Join me=

--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Errata ID: 1326


My recommendation is that this errata be accepted "Pending Update". 
=



Status: Reported

Type: Technical



Reported By: Alfred Hoenes

Date Reported: 2008-02-17



Throughout the document=2C when it says:



a)       header

b)       headers

c)=
       Header

It should say:


a)       header field

b)       header fiel=
ds

c)       Header Field

Notes:



As a Standards Track document=2C RFC 5090 should use established

IETF standard terminology=2C and not fall back to common sluggish

and confusing terminology.  Concise Ref.:  RFC 4249=2C Section 3.1.1.



There are 24 instances of case a) throughout the RFC=3B

only Section 3.20 makes proper use of the IETF standard

terminology=3B case b) occurs twice in the RFC=3B

case c) applies to the title of Section 2.1.3.









3D"i'm" EMAILING FOR THE G=
REATER GOOD
Join me<=
/td>

=

--_ffb47776-6c14-4d11-a073-92c4bb88ac6b_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:10:32 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_3901da34-350f-4435-b4be-0507c9478d20_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #867 (RFC 4668)
Date: Tue, 8 Sep 2009 08:09:23 -0700
MIME-Version: 1.0

--_3901da34-350f-4435-b4be-0507c9478d20_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










[BA] IMHO=2C Alfred is correct that RFC 4668 covers both IPv4 and IPv6.=20
Since the abstract makes this clear=2C I don't think that the title needs t=
o be changed.=20

With respect to the term "MIB module"=2C I would agree with Alfred that the=
 term
"MIB" would have been more appropriate.

Overall I'd recommend that this errata be accepted "Pending Revision".=20


Status: Reported

Type: Editorial



Reported By: Alfred Hoenes

Date Reported: 2006-11-06




misleading RFC title=2C including abuse of defined terms
(for RFCs 4668 - 4671)

IMHO=2C the RFC titles=2C "RADIUS ... MIB for IPv6" are misleading.
In fact=2C the new RFCs extend the RADIUS MIB modules to cover
IPv6=2C but they are not IPv6 specific!
Perhaps=2C better wording would have been "... for IPv4 and IPv6".

Furthermore=2C a very 'popular' clash of terms shines up here.
As specified in RFC 3410 and Part 1 of STD 62=2C RFC 3411=2C and
re-stated in the boilerplate Section 3=2C "The Internet-Standard
Management Framework"=2C of all four RFCs=2C there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus=2C throughout the titles and the text bodies of the RFCs=2C the
proper term=2C "RADIUS ... MIB module" should be used instead of the
rather sluggish "RADIUS ... MIB".



--_3901da34-350f-4435-b4be-0507c9478d20_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














[BA] IMHO=2C Alfred is correct that RFC 4668 covers both IPv4 and IPv6. =

Since the abstract makes this clear=2C I don't think that the title nee=
ds to be changed. 

With respect to the term "MIB module"=2C I would =
agree with Alfred that the term
"MIB" would have been more appropriate.<=
br>
Overall I'd recommend that this errata be accepted "Pending Revision=
". 


Status: Reported

Type: Editorial



Reported By: Alfred Hoenes

Date Reported: 2006-11-06





misleading RFC title=2C including abuse of define=
d terms
(for RFCs 4668 - 4671)

IMHO=2C the RFC titles=2C "RADIUS =
... MIB for IPv6" are misleading.
In fact=2C the new RFCs extend the RAD=
IUS MIB modules to cover
IPv6=2C but they are not IPv6 specific!
Perh=
aps=2C better wording would have been "... for IPv4 and IPv6".

Furth=
ermore=2C a very 'popular' clash of terms shines up here.
As specified i=
n RFC 3410 and Part 1 of STD 62=2C RFC 3411=2C and
re-stated in the boil=
erplate Section 3=2C "The Internet-Standard
Management Framework"=2C of =
all four RFCs=2C there's just one single
Management Information Base (MI=
B) comprised of various "MIB modules".
Thus=2C throughout the titles and=
 the text bodies of the RFCs=2C the
proper term=2C "RADIUS ... MIB modul=
e" should be used instead of the
rather sluggish "RADIUS ... MIB".



=

--_3901da34-350f-4435-b4be-0507c9478d20_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 15:00:33 +0000
Message-ID: <4AA67153.2090506@deployingradius.com>
Date: Tue, 08 Sep 2009 16:59:31 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: RADIUS Errata #1407 (RFC 5176)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> *My recommendation is that this errata be accepted.  As Avi points out,
> the CUI attribute is opaque and therefore not parseable by the Dynamic
> Authorization Server.

  I agree.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 08 Sep 2009 08:25:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Test
Date: Tue, 8 Sep 2009 10:24:05 +0200
Message-ID: 
Thread-Topic: Test
Thread-Index: Acov/lV3Bqknp3beRJG+omKWHCt6TAAX1stQ
From: 
To: , 

I have them in my inbox! ;)

Lionel=20

> -----Message d'origine-----
> De : owner-radiusext@ops.ietf.org=20
> [mailto:owner-radiusext@ops.ietf.org] De la part de Alan DeKok
> Envoy=E9 : lundi 7 septembre 2009 22:27
> =C0 : 'radext mailing list'
> Objet : Test
>=20
>=20
>   Is the mailing list fixed?  My earlier posts aren't in the=20
> archives...
>=20
>   Did anyone other than Bernard see my comments on the issues=20
> in the guidelines document?
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: 
>=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 07 Sep 2009 21:59:22 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ioGZ2K7UtcsVS6zgj0VVXnCW+dQ6PAkcmjmgCQKZxsE=; b=mt3LOR//7h8vkq1xTW0Z1LktdXp5yPU9p1ml/wcoAfSYR13v0qiQo2YI7EvJzquXk8 w+XmIYGG1Nv8UuHEqnX83JOApVSXxvJILmbnpVibYPug/yUPmc8hu8woQ4KBf4UrD3X5 j+AB+jD475kixIxZr6R2bazJOydfn2lyDr4Zw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eBJ9ioGz2rI2YlI5+BBCrBF9/QluBUP8F5b27dLeyQqt7/5TpURpiEM5F/OMJKbu/4 aYUkp4u5tjY4s+TgHHUwOoCtOdFRjd8QvWKQ4ySOdPHNaJYGiz/7xjR+v4efBkeRD6mq lsMnYpFkp4BkPAEF+QNO2xVEfSuc1f7aZkeQ8=
MIME-Version: 1.0
Date: Mon, 7 Sep 2009 17:09:36 -0400
Message-ID: 
Subject: Re: Test
From: Greg Weber 
To: Alan DeKok 
Cc: radext mailing list 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 7, 2009 at 4:26 PM, Alan DeKok wrote=
:
> =A0Is the mailing list fixed? =A0My earlier posts aren't in the archives.=
..
>
> =A0Did anyone other than Bernard see my comments on the issues in the
> guidelines document?

Yes.  They appear to have gone to the list, but not the archive.

Greg

>
> =A0Alan DeKok.
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 07 Sep 2009 20:58:47 +0000
Message-ID: <4AA56C7C.2070203@deployingradius.com>
Date: Mon, 07 Sep 2009 22:26:36 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: 'radext mailing list' 
Subject: Test
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  Is the mailing list fixed?  My earlier posts aren't in the archives...

  Did anyone other than Bernard see my comments on the issues in the
guidelines document?

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Mon, 07 Sep 2009 19:17:13 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_51481470-7a9c-4acb-9722-06e329bc25e8_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: RADIUS Errata #1407 (RFC 5176)
Date: Mon, 7 Sep 2009 11:34:55 -0700
MIME-Version: 1.0

--_51481470-7a9c-4acb-9722-06e329bc25e8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


My recommendation is that this errata be accepted.  As Avi points out=2C=20
the CUI attribute is opaque and therefore not parseable by the Dynamic
Authorization Server.=20


Status: Reported

Type: Technical



Reported By: Avi Lior

Date Reported: 2008-04-09


Section 6.1 says:


Typically=2C the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name or Chargeable-User-Identity Attribute=2C and determine the
   corresponding RADIUS servers in the realm routing tables.

It should say:

Typically=2C the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name and determine the
   corresponding RADIUS servers in the realm routing tables.

Notes:


Chargeable-User-Identity Attribute defined in RFC4372 does not allow
any entity other then the home network to parse the CUI attribute. It
is in essence opaque. Here is the text:

"RADIUS entities other than the Home RADIUS

      server MUST treat the CUI content as an opaque token=2C and SHOULD

      NOT perform operations on its content other than a binary equality

      comparison test=2C between two instances of CUI."






 EMAILING FOR THE GREATER GOOD
Join me=

--_51481470-7a9c-4acb-9722-06e329bc25e8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






My recommendation is that this errata be accepted. =3B As Avi points=
 out=2C 
the CUI attribute is opaque and therefore not parseable by the =
Dynamic
Authorization Server. 


Status: Reported

Type: Technical



Reported By: Avi Lior

Date Reported: 2008-04-09


Section 6.1 says:



Typically=2C the Dynamic Authorization Server will e=
xtract the realm
   from the Network Access Identifier [RFC4282] include=
d within the
   User-Name or Chargeable-User-Identity Attribute=2C and d=
etermine the
   corresponding RADIUS servers in the realm routing tables=
.

It should say:


Typically=2C the Dynamic Authorization Server will e=
xtract the realm
   from the Network Access Identifier [RFC4282] include=
d within the
   User-Name and determine the
   corresponding RADIUS s=
ervers in the realm routing tables.

Notes:



Chargeable-User-Identity Attribute defined in RFC4372 does not allow
any entity other then the home network to parse the CUI attribute. It
is in essence opaque. Here is the text:

"RADIUS entities other than the Home RADIUS

      server MUST treat the CUI content as an opaque token=2C and SHOULD
      NOT perform operations on its content other than a binary equality
      comparison test=2C between two instances of CUI."







3D"i'm" EMAILING FOR THE G=
REATER GOOD
Join me<=
/td>

=

--_51481470-7a9c-4acb-9722-06e329bc25e8_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 06 Sep 2009 22:13:38 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 06 Sep 2009 22:04:43 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 06 Sep 2009 20:55:09 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Sun, 06 Sep 2009 20:46:07 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
Subject: I-D Action:draft-ietf-radext-design-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090906200003.2B9AC3A699F@core3.amsl.com>
Date: Sun,  6 Sep 2009 13:00:02 -0700 (PDT)

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-08.txt
	Pages           : 36
	Date            : 2009-09-06

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2009-09-06124703.I-D@ietf.org>

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Fri, 04 Sep 2009 22:50:03 +0000
Message-ID: <4AA17D7B.1000108@deployingradius.com>
Date: Fri, 04 Sep 2009 22:50:03 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>> The design guidelines document can talk about things that exist today.
>> if other documents add new RADIUS functionality, they can mention that
>> they update the design guidelines document.
> 
> Seems reasonable to me.  Could you post a proposal on text to be deleted?

  All text that references [EXTEN], or extended attributes. A quick pass
through the document yeilds:

   Specifications that do not follow the
   guidelines articulated herein or in [EXTEN] are NOT RECOMMENDED.
->
   Specifications that do not follow the
   guidelines articulated herein are NOT RECOMMENDED.
   Changes to the RADIUS data model are NOT
   RECOMMENDED, but if performed, SHOULD follow the IETF process.

  i.e. we can't retro-actively forbid the various SDOs from adding all
kinds of stuff to the data model.


   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.  New attributes SHOULD use the grouping
   method described in [EXTEN].
->
   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.


2.2.  Extended RADIUS Attributes
->
	


  In Section 2.3:

   If additional functionality is required, the format defined in
   [EXTEN] SHOULD be used, with a non-zero Vendor-Id field.
->
	
	


  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Fri, 04 Sep 2009 17:53:41 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_"
From: Bernard Aboba 
To: Alan DeKok 
CC: "radiusext@ops.ietf.org" 
Subject: RE: Issue 311: IESG DISCUSS comments
Date: Fri, 4 Sep 2009 09:48:03 -0700
MIME-Version: 1.0

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


looks good.


> Date: Fri=2C 4 Sep 2009 10:13:07 +0200
> From: aland@deployingradius.com
> To: bernard_aboba@hotmail.com
> CC: radiusext@ops.ietf.org
> Subject: Re: Issue 311: IESG DISCUSS comments
>=20
> Bernard Aboba wrote:
> > You might also mention that firewalls and other filtering devices often
> > discard fragments.
>=20
>   OK.
>=20
> > Jari is correct that allocation requests will be handled according to
> > RFC 3575=2C
> > but as part of the Expert Review process=2C Design Guidelines will
> > presumably be
> > consulted.  So while self-allocation is certainly not a good practice=
=2C
> > the whole
> > point of IANA allocation is to enable consistent allocation.  Perhaps
> > the text
> > can be clear that the recommendations are relevant to Expert Reviewers
> > appointed under the IANA considerations of RFC 3575=2C not for IANA its=
elf.
>=20
>   OK.  I suggest adding a first bullet about this point to the IANA
> considerations section:
>=20
> ...
> This document does not require that the IANA update any existing
> registry or create any new registry=2C but includes information that
> affects the IANA=2C which:
>=20
> * includes specific guidelines for Expert Reviewers appointed
>   under the IANA considerations of [RFC3575]
> * includes guidelines that recommend against self allocation from
>   ...
>=20
>   Alan DeKok.

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






looks good.


>=3B Date: Fri=2C 4 Sep 2009 10:13:07 +0200
>=
=3B From: aland@deployingradius.com
>=3B To: bernard_aboba@hotmail.com=

>=3B CC: radiusext@ops.ietf.org
>=3B Subject: Re: Issue 311: IES=
G DISCUSS comments
>=3B 
>=3B Bernard Aboba wrote:
>=3B >=
=3B You might also mention that firewalls and other filtering devices often=

>=3B >=3B discard fragments.
>=3B 
>=3B   OK.
>=3B <=
br>>=3B >=3B Jari is correct that allocation requests will be handled a=
ccording to
>=3B >=3B RFC 3575=2C
>=3B >=3B but as part of th=
e Expert Review process=2C Design Guidelines will
>=3B >=3B presumab=
ly be
>=3B >=3B consulted.  So while self-allocation is certainly no=
t a good practice=2C
>=3B >=3B the whole
>=3B >=3B point of I=
ANA allocation is to enable consistent allocation.  Perhaps
>=3B >=
=3B the text
>=3B >=3B can be clear that the recommendations are rel=
evant to Expert Reviewers
>=3B >=3B appointed under the IANA conside=
rations of RFC 3575=2C not for IANA itself.
>=3B 
>=3B   OK.  I s=
uggest adding a first bullet about this point to the IANA
>=3B conside=
rations section:
>=3B 
>=3B ...
>=3B This document does not =
require that the IANA update any existing
>=3B registry or create any =
new registry=2C but includes information that
>=3B affects the IANA=2C=
 which:
>=3B 
>=3B * includes specific guidelines for Expert Revi=
ewers appointed
>=3B   under the IANA considerations of [RFC3575]
&=
gt=3B * includes guidelines that recommend against self allocation from
=
>=3B   ...
>=3B 
>=3B   Alan DeKok.

=

--_9e9373da-36c5-4c3d-81b5-6c8b6f7c5d35_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Fri, 04 Sep 2009 08:21:48 +0000
Message-ID: <4AA0CDEE.8040109@deployingradius.com>
Date: Fri, 04 Sep 2009 10:21:02 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> The reason why we ended up with a normative reference was because there
> were normative statements preceeding the reference.  So I don't think it's
> enough just to change the reference to informative; you'll also need to
> change
> the text.

  I think it's simplest to simply remove all references to the extended
attributes document.  We can then mark it as updating the design
guidelines document, to permit the extended attribute format.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Fri, 04 Sep 2009 08:14:24 +0000
Message-ID: <4AA0CC13.3010906@deployingradius.com>
Date: Fri, 04 Sep 2009 10:13:07 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 311: IESG DISCUSS comments
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> You might also mention that firewalls and other filtering devices often
> discard fragments.

  OK.

> Jari is correct that allocation requests will be handled according to
> RFC 3575,
> but as part of the Expert Review process, Design Guidelines will
> presumably be
> consulted.  So while self-allocation is certainly not a good practice,
> the whole
> point of IANA allocation is to enable consistent allocation.  Perhaps
> the text
> can be clear that the recommendations are relevant to Expert Reviewers
> appointed under the IANA considerations of RFC 3575, not for IANA itself.

  OK.  I suggest adding a first bullet about this point to the IANA
considerations section:

...
This document does not require that the IANA update any existing
registry or create any new registry, but includes information that
affects the IANA, which:

* includes specific guidelines for Expert Reviewers appointed
  under the IANA considerations of [RFC3575]
* includes guidelines that recommend against self allocation from
  ...

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 03 Sep 2009 16:33:38 +0000
Message-ID: <4A9FE058.3050500@deployingradius.com>
Date: Thu, 03 Sep 2009 17:27:20 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 311: IESG DISCUSS comments
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> The first issue is that Section 2.3 suggests 16-bit vendor space
> attribute number fields to replace the existing 8-bit recommendation.
> 
> There are a couple of problems with this. First, if you really mean
> to change the recommendation, then Updates: RFC 2865 header in the
> beginning of the document would have been appropriate.

  Can a BCP update a standards track document?

> Secondly, while I agree with the advice of going for 16 bits, the
> document is silent on some of the issues involved in such a change,
> such as:
> 
> - Does RADIUS dictionary software support the VSA format for 16 bits, 8
>   bits, or both?

  Most common RADIUS implementations support both.

> - How do you cleanly print or report VSAs when you do not know if the
>   field size is 8 or 16 bits? I realize that this situation already
>   exists since the format was never required to be followed, but
>   your new recommendation makes a potential problem much more likely
>   to appear. Previously, you could print something like Vendor = ACME,
>   Code = 17, Contents = ABCDEF0011... Now you couldn't do that.

  The key is that VSAs depend on a Vendor-Id.  See below.

> - Can a vendor who moved from 8 bits to 16 bits deal with this?

  Suggested text to resolve this issue:

Although [RFC2865] does not mandate it, implementations commonly
assume that the Vendor Id can be used as a key to determine the
on-the-wire format of a VSA.  Vendors therefore SHOULD NOT use
multiple formats for VSAs that are associated with a particular Vendor
Id.  A vendor wishing to use multiple VSA formats, SHOULD request one
Vendor Id for each VSA format that they will use.

> Comment [2009-05-07]:
> I do agree that for functionality FOO, both the functionality itself
> and the MIB, RADIUS, etc. work should take place in the same standards
> body. However, Section 3.1 could have said a couple of additional things
> as well:
> 
> The issues of attribute space and choice of forum are distinct; there
> is no reason why IETF couldn't use its own vendor code, for instance.

  Yes.  I don't see a need to mention that in this document.

> The section also does not mention one of the potential drawbacks of
> SDO-driven development model: it is easy to come up with a number of
> different solutions to the same generic problem, as opposed to finding
> a common solution.

  Section 3.1.3 says:

   Any new RADIUS attributes or values intended for interoperable use
   across a broad spectrum of the Internet Community SHOULD follow the
   normal IETF process, and SHOULD result in allocations from the RADIUS
   standard space.

> Ralph Droms:
> 
> Comment [2009-04-20]:
> Trivial: does the "text" data type include a trailing '\0' byte?  I ask because
> there has been confusion about this point in DHCP options and it might be good
> to make the convention explicit.

 RFC 2865 Section 5 already states explicitly that trailing '\0' bytes
are not to be used.

> Lars Eggert:
> 
> Comment [2009-04-20]:
> 
> Section 2.1.1, paragraph 2:
>>    The Length field in the RADIUS packet header is defined in [RFC2865]
>>    Section 3.  It is noted there that the maximum length of a RADIUS
>>    packet is 4096 octets.  As a result, attribute designers SHOULD NOT
>>    assume that a RADIUS implementation can successfully process RADIUS
>>    packets larger than 4096 octets.
> 
>   You may want to point out that even with messages less than 4096 but
>   larger than the PMTU, persistent IP fragmentation will be incurred,
>   which makes communication much more brittle, and might even want to
>   suggest that therefore RADIUS messages should be kept as small as
>   possible. See RFC5405 Section 3.2.

  Suggested text in 2.1.1:

Even when packets are less than 4096 octets, they may be larger than
the Path Maximum Transmission Unit (PMTU).  Any packet larger than the
PMTU will be fragmented, making communications more brittle.
Transport of fragmented UDP packets appears to be a poorly tested code
path on network devices.  Some devices appear to be incapable of
transporting fragmented UDP packets, making it difficult to deploy
RADIUS in a network where those devices are deployed.  We RECOMMEND
that RADIUS messages be kept as small possible.


> Adrian Farrel:
> 
> Comment [2009-04-18]:
> Trivial, but...
> Section 2.1.1 says that some address data types are in "network
> byte order" while others are "most significant octet first". Is there a reason
> for this difference?

  Tradition.  I suggest changing all references to use "in network byte
order".

> I wonder if the text in seciton 4 should be stronger. You have...
> 
>    This document does not require that the IANA update any existing
>    registry or create any new registry, but includes information that
>    affects the IANA, for example:
> 
>       * includes guidelines that recommend against allocation from the
>         RADIUS standard attribute space in other SDO RADIUS Attribute
>         specifications.
> 
> But, in fact, IANA are bound by the registry rules already laid down and cannot
> make allocations except following IETF process as defined by RFC 3575.

  I think that's what the above text says.  Maybe the text could say:

	... recommend against SELF allocation ...

  The idea is to tell the SDOs that it's a bad idea to avoid IANA.

> Russ Housley:
> 
> Comment [2009-04-20]:
> 
>   The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
>   editorial suggestions.
> 
>   ID nits complains that reference [8] appears in Appendix B.6 but not
>   in the References.

  It's a quote from another document.

>   The Introduction Section should be a non-normative section. However,
>   Section 1.1 uses normative statements (RECOMMENDED and NOT
>   RECOMMENDED) before those terms are defined in Section 1.3.

  The simplest thing to do is to move Section 1.1 to be after the
current Section 1.3.

>   The acronym AAA should be expanded.

  OK, fixed.

>   When referring to the appendixes, I think the draft should talk about
>   appendixes, not about sections. For example, it should talk about
>   Appendix A.5, not about Section A.5.

  OK, fixed.

> Alexey Melnikov:
> 
> Comment [2009-04-21]:
> This is a fine document. Some minor comments:
> 
> 3.3.  RADIUS Operational Model
> 
>    The RADIUS operational model includes several assumptions:
> 
>       * The RADIUS protocol is stateless;
>       * Provisioning of services is not possible within an
>         Access-Reject;
>       * Distinction between authorization checks and user
>         authentication;
>       * Authentication and integrity protection of RADIUS packets;
>       * The RADIUS protocol is a Request/Response protocol.
>       * Packet length restriction.
> 
> Half of this list is comprised from full sentences, the other half is not. I
> would appreciate if you can make this consistent, otherwise it
> is difficult to read/understand.

  I suggest the following re-write:

* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
  Access-Reject;
* There is a distinction between authorization checks and user
  authentication;
* The protocol provices for authentication and integrity
  protection of packets;
* The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions.

> Tim Polk:
> 
> Comment [2009-05-06]:
> It might be valuable to supplement the current security considerations section
> with a discussion of issues that arise if SDOs do not follow the guidelines
> presented here. For example, relying on MTU discovery to support transporting
> large amounts of data could fail and result in denial of service, lost
> accounting data, etc...

  Suggested text:

Implementations not following the suggestions outlined in this
document may be subject to a problems such as ambiguous protocol
decoding, packet loss leading to loss of billing information, and
denial of service attacks.

> Robert Sparks:
> 
> Comment [2009-04-22]:
> "the above procedure" in 3.1.1 (page 17) could be hard to follow for some
> readers. Recommend providing a more explicit pointer.

  It should say "IETF process" instead of "the above procedure".

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 03 Sep 2009 13:28:02 +0000
Message-ID: <4A9FC45A.7090702@deployingradius.com>
Date: Thu, 03 Sep 2009 15:27:54 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 312:  Normative Reference to Extended Attributes Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> In Section 2.2 and 3 the Design Guidelines document contains normative
> language relating to the Extended Attributes document.  This has
> resulted in a normative dependency on that document.  Given that the
> Extended Attributes document is not yet completed, and can contain its
> own usage guidelines, is the normative reference appropriate?

  No.  The reference should be informative.

  I think it would be OK to simply move the [EXTEN] document from the
"normative" to "informative" section of the references.  Nothing in the
design guideline documents depends on [EXTEN], so there's no reason to
have a normative dependency.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 03 Sep 2009 13:23:41 +0000
Message-ID: <4A9FC353.3050104@deployingradius.com>
Date: Thu, 03 Sep 2009 15:23:31 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 313:  Security Exemption
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

>   RADIUS could transport parameters for *another* protocol.  Those
> attributes are not security related.  They either follow the RADIUS data
> model (int, IP address, etc.), or they are "opaque data" that RADIUS is
> simply transporting on the behalf of the other protocol.

  Suggested text in Section A.2.2.:

A.2.2. Complex Data Types

   Does the attribute:

   * define a complex data type
   * that the RADIUS server and/or client will not treat as opaque data
     (see Section A.1.3)
   * for purposes other than authentication or security?

   If the answers to all of the above items are "yes", this data type
   SHOULD be replaced
   with simpler types, as discussed above in Section A.2.1.  Also see
   Section 2.1.3 for a discussion of why complex types are problematic.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 03 Sep 2009 13:16:08 +0000
Message-ID: <4A9FC16C.9020600@deployingradius.com>
Date: Thu, 03 Sep 2009 15:15:24 +0200
From: Alan DeKok 
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Bernard Aboba 
CC: "radiusext@ops.ietf.org" 
Subject: Re: Issue 314:  My Problem
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> The document assumes a certain implementation and processing model.

  Maybe the document isn't clear.  It assumes a certain *data* model for
RADIUS.  It assumes that maintaining that data model is a good idea.  It
explicitly states that a *typical* RADIUS server uses a data dictionary:

  Section 2.1.3 says:

   ... RADIUS server implementations
   typically provide support for basic data types, and define attributes
   in a data dictionary.  ...

  Maybe this should be "MANY RADIUS server implementations..."

  Or "RADIUS server implementations have traditionally provided support..."

> This
> model is not explicitly documented in the draft and unfortunately has
> implications on the design of attributes particularly when it comes to data
> types used by RADIUS attributes and for the claimed problems that arise from
> adding new code to the RADIUS server.  

  Even if an implementation can easily handle complex attributes defined
in a "dictionary", is there any *reason* to use complex attributes where
the standard data types would be sufficient?

  If not, then the existing text would seem to be sufficient.

> In previous mail exchanges on the list I did not agree with certain aspects
> of the implicitly assumed progressing model. I am, however, OK with
> documenting the model and to thereby make it explicit to the reader. The
> understanding of some of the claimed limitations might also be clearer.

  The draft explicitly mentions a *typical* data model implemented by a
RADIUS server.

  As for making the limitations clear, the document already does that.
It states that the data dictionary approach means that it allows:

   ... RADIUS servers to be configured to support new attributes
   without requiring server code changes.  ...

  Should we add some text here saying:

  "Some implementations can support more complex attributes defined in a
more complex dictionary than is traditional.  However, this document
does not recommend defining complex attributes for all of the reasons
outlined in Section 2.1.3"

  I fail to see how that will help.

  The text allows more complex implementations of dictionaries.  Nothing
in the text *forbids* more complex implementations of dictionaries.
Nothing in the text suggests that it is a good idea to use complex types
where standard types would suffice.  The document already discusses the
typical model, along with its limitations.

  So... why do we need to say any more?

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 03 Sep 2009 00:30:44 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Issue 314:  My Problem
Date: Wed, 2 Sep 2009 17:30:27 -0700
MIME-Version: 1.0

--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue 314: My Problem

Submitter name: Hannes Tschofenig =20

Submitter email address: Hannes.Tschofenig@gmx.net

Date first submitted:  May 9=2C 2009

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html

Document:=20
Design-Guidelines=20


Comment type: Technical=20

Priority: S =20

Section: Various =20

Rationale/Explanation of issue:
The document assumes a certain implementation and processing model. This
model is not explicitly documented in the draft and unfortunately has
implications on the design of attributes particularly when it comes to data
types used by RADIUS attributes and for the claimed problems that arise fro=
m
adding new code to the RADIUS server.=20

In previous mail exchanges on the list I did not agree with certain aspects
of the implicitly assumed progressing model. I am=2C however=2C OK with
documenting the model and to thereby make it explicit to the reader. The
understanding of some of the claimed limitations might also be clearer.
PS: FYI=2C I stated my concerns previously on the RADEXT list.

[Alan DeKok] Do you have suggested text for the document?
[Hannes]=20
I can compile some text but this is not saying that I agree with the assume=
d
model=2C i.e. one where essentially no improvement in implementations was m=
ade
over the last 10 years.=20
[David Nelson]=20
Perhaps=2C but this seems to presume that data-dictionary-driven server
implementations are a liability which requires improvement.  Like a network
management application for SNMP which has the ability to "enroll" a MIB
module without code changes=2C a RADIUS server that can simply add new
attributes to its dictionary is a boon to users.

We can split hairs about what types of user-added executable scripts are or
are not "coding".  I still think that the data dictionary architecture is a
very powerful concept.  Not to mention a very widely deployed one.


--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Issue 314: My Problem

Submitter name: Hannes Tschofenig =3B 

Submitter email address: Hannes.Tschofenig@gmx.net

Date first submitted: =3B May 9=2C 2009

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html

Document:=20
Design-Guidelines=20


Comment type: Technical 

Priority: S =3B 

Section: =3BVarious =3B 

Rationale/Explanation of issue:

The document assumes a certain implementation and processing model. Th=
is
model is not explicitly documented in the draft and unfortunately has=

implications on the design of attributes particularly when it comes to =
data
types used by RADIUS attributes and for the claimed problems that a=
rise from
adding new code to the RADIUS server. 

In previous mail=
 exchanges on the list I did not agree with certain aspects
of the impli=
citly assumed progressing model. I am=2C however=2C OK with
documenting =
the model and to thereby make it explicit to the reader. The
understandi=
ng of some of the claimed limitations might also be clearer.


PS: FYI=2C I stated my concerns previously on the RADEXT list.


[Alan DeKok] Do you have suggested text for the document?


[Hannes] 


I can compile some text but this is not saying that I agree with the a=
ssumed
model=2C i.e. one where essentially no improvement in implementat=
ions was made
over the last 10 years. 


[David Nelson] 


Perhaps=2C but this seems to presume that data-dictionary-driven serve=
r
implementations are a liability which requires improvement.  Like a ne=
twork
management application for SNMP which has the ability to "enroll" =
a MIB
module without code changes=2C a RADIUS server that can simply add=
 new
attributes to its dictionary is a boon to users.

We can spli=
t hairs about what types of user-added executable scripts are or
are not=
 "coding".  I still think that the data dictionary architecture is a
ver=
y powerful concept.  Not to mention a very widely deployed one.


=

--_f0b75334-ca44-4f65-b195-bb7a6aa6adf9_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 03 Sep 2009 00:27:19 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_b155f041-0060-4939-8440-679293bec851_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: REMINDER:  Ongoing RADEXT WG last call on "RADIUS over TCP"
Date: Wed, 2 Sep 2009 17:26:57 -0700
MIME-Version: 1.0

--_b155f041-0060-4939-8440-679293bec851_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a reminder of an ongoing RADEXT WG last call on "RADIUS over TCP"=
=2C prior to sending this document on to the IESG for
publication as an Experimental RFC.  The document is available for
inspection here:

http://tools.ietf.org/html/draft-ietf-radext-tcp-transport



The original RADEXT
WG last call lasted until August 7=2C 2009=2C but no comments were received=
.  We will therefore extend the comment period until October 2=2C 2009. Ple=
ase send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list: http://www.drizzle.com/~aboba/RADEXT/




--_b155f041-0060-4939-8440-679293bec851_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






This is a reminder of an ongoing RADEXT WG last call on "RADIUS over TCP"=
=2C prior to sending this document on to the IESG for
publication as an Experimental RFC. =3B The document is available for
inspection here:

http://tools.ietf.org/html/draft-ietf-radext-tcp-transport



The original RADEXT
WG last call lasted until August 7=2C 2009=2C but no comments were received=
. =3B We will therefore extend the comment period until October 2=2C 20=
09. Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list: http://www.drizzle.com/~aboba/RADEXT/




=

--_b155f041-0060-4939-8440-679293bec851_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Thu, 03 Sep 2009 00:18:38 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: REMINDER:  Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item
Date: Wed, 2 Sep 2009 17:18:15 -0700
MIME-Version: 1.0

--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a reminder of the ongoing call for review of the document "DTLS as =
a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item.  This document is
being targeted at Experimental
status.=20

=20
The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-dtls

The original call for review expired August 7=2C 2009=2C but no comments we=
re received.  This call for input will last until October 2=2C 2009.  Pleas=
e send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.  If you have comments on the
document=2C please also send these to the list in the format described on
the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/


--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






This is a reminder of the ongoing call for review of the document "DTLS as =
a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item. =3B This document is
being targeted at Experimental
status. 

 =3B
The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-dtls
The original call for review expired August 7=2C 2009=2C but no commen=
ts were received. =3B This call for input will last until October 2=2C =
2009. =3B Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item. =3B If you have comments on the
document=2C please also send these to the list in the format described on
the RADEXT WG Issues list:
http://ww=
w.drizzle.com/~aboba/RADEXT/


=

--_c991cd22-a50d-4da3-bf9a-1e22acb6f42a_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 23:58:10 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Issue 313:  Security Exemption
Date: Wed, 2 Sep 2009 16:57:42 -0700
MIME-Version: 1.0

--_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


HTML clipboardIssue 313: Security Exemption

Submitter name: Alan DeKok =20

Submitter email address:  aland@deployingradius.com

Date first submitted: July 24=2C 2009 =20

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00340.html

Document:=20
Design Guidelines

Comment type: Technical=20

Priority: S =20

Section:  A.2.1

Rationale/Explanation of issue:

Section A.2.1 states:

      * Complex data structures defined only within RADIUS.
        The additional functionality defined in [EXTEN] SHOULD be used
        instead.  This recommendation does not apply to new attributes
        for authentication or security=2C as described below in Section
        A.2.2.
Should this exemption be removed and/or clarified?
d.b.nelson@comcast.net wrote:
> Yeah.  I've always been a bit uncomfortable with the "security
> functionality" escape clause in the RADIUS Design Guidelines draft.=20
> Lots of things can reasonably be claimed to be "security related".  I
> would have preferred the exception to be crafted a bit narrower=2C just
> for this reason.  But=2C unless wording of Design Guidelines is changed=
=2C
> you have a legitimate argument.

  I believe the intent was "related to RADIUS security".  The guidelines
document could be updated to address this.

  RADIUS could transport parameters for *another* protocol.  Those
attributes are not security related.  They either follow the RADIUS data
model (int=2C IP address=2C etc.)=2C or they are "opaque data" that RADIUS =
is
simply transporting on the behalf of the other protocol.
Proposed Resolution: Discuss






 EMAILING FOR THE GREATER GOOD
Join me=

--_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






HTML clipboard=
Issue 313: Security Exemption

Submitter name: Alan DeKok =3B 

Submitter email address: =3B aland@deployingradius.com

Date first submitted: July 24=2C 2009 =3B 

Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00340.html

Document:=20
Design Guidelines

Comment type: Technical 

Priority: S =3B 

Section: =3B =3BA.2.1

Rationale/Explanation of issue:

Section A.2.1 states:


      * Complex data structures defined only within =
RADIUS.
        The additional functionality defined in [E=
XTEN] SHOULD be used
        instead.  This recommendation does not apply to new attributes
        for authentication or security=2C as described below in Section
        A.2.2.


Should this exemption be removed and/or clarified?

d.b.nelson@comcast.net wrote:
>=3B Yeah.  I've always been a bit uncomfortable with the "security
>=3B functionality" escape clause in the RADIUS Design Guidelines draft.=
=20
>=3B Lots of things can reasonably be claimed to be "security related".  =
I
>=3B would have preferred the exception to be crafted a bit narrower=2C j=
ust
>=3B for this reason.  But=2C unless wording of Design Guidelines is chan=
ged=2C
>=3B you have a legitimate argument.

  I believe the intent was "related to RADIUS security".  The guidelines
document could be updated to address this.

  RADIUS could transport parameters for *another* protocol.  Those
attributes are not security related.  They either follow the RADIUS data
model (int=2C IP address=2C etc.)=2C or they are "opaque data" that RADIUS =
is
simply transporting on the behalf of the other protocol.

Proposed Resolution: Discuss






3D"i'm" EMAILING FOR THE GREATER G=
OOD
Join me

=

--_f94f3e56-8e81-4f07-b54c-20f5f2f51f9c_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 23:52:08 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_73b09e04-e9be-410b-b709-1f5ee1f52453_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Issue 312:  Normative Reference to Extended Attributes Document
Date: Wed, 2 Sep 2009 16:51:45 -0700
MIME-Version: 1.0

--_73b09e04-e9be-410b-b709-1f5ee1f52453_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


HTML clipboardIssue 312: Normative Reference to Extended Attributes Documen=
t

Submitter name: Bernard Aboba =20

Submitter email address: bernard_aboba@hotmail.com=20

Date first submitted: July 31=2C 2009 =20

Reference:=20


Document:=20
Design-Guidelines=20


Comment type: Editorial=20

Priority: S =20

Section: 2.2=2C 3=2C 6.1 =20

Rationale/Explanation of issue:

In Section 2.2 and 3 the Design Guidelines document contains normative=20
language relating to the Extended Attributes document.  This has resulted=20
in a normative dependency on that document.  Given that the Extended=20
Attributes document is not yet completed=2C and can contain its own usage=20
guidelines=2C is the normative reference appropriate?=20


2.2. Extended RADIUS Attributes
The extended RADIUS attribute document [EXTEN]=20
defines a number of extensions to RADIUS. The standard attribute space is=20
extended by permitting standard allocations from within a specific subset o=
f the=20
VSA space=3B the format of extended attributes is defined=3B and extended d=
ata types=20
are defined within that format. New specifications seeking to extend the=20
standard RADIUS data model SHOULD examine [EXTEN]=20
to see if their needs fit within the extended RADIUS data model.From Sectio=
n=20
3:=20

   Recent extensions to the RADIUS data model such as [EXTEN] make it
   possible to minimize the use of complex attributes.  New
   specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their needs fit within the extended
   RADIUS data model.
Proposed Resolution: Discuss







 EMAILING FOR THE GREATER GOOD
Join me=

--_73b09e04-e9be-410b-b709-1f5ee1f52453_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






HTML clipboard=
Issue 312: Normative Reference to Extended Attributes Docum=
ent

Submitter name: Bernard Aboba =3B 

Submitter email address: bernard_aboba@hotmail.com 

Date first submitted: July 31=2C 2009 =3B 

Reference: =3B


Document:=20
Design-Guidelines=20


Comment type: Editorial 

Priority: S =3B 

Section: =3B2.2=2C 3=2C 6.1 =3B 

Rationale/Explanation of issue:

In Section 2.2 and 3 the Design Guidelines document contains normative=20
language relating to the Extended Attributes document. =3B This has res=
ulted=20
in a normative dependency on that document. =3B Given that the Extended=
=20
Attributes document is not yet completed=2C and can contain its own usage=20
guidelines=2C is the normative reference appropriate? 



2.2. Extended RADIUS Attributes

The extended RADIUS attribute document [EXT=
EN]=20
defines a number of extensions to RADIUS. The standard attribute space is=20
extended by permitting standard allocations from within a specific subset o=
f the=20
VSA space=3B the format of extended attributes is defined=3B and extended d=
ata types=20
are defined within that format. New specifications seeking to extend the=20
standard RADIUS data model SHOULD examine [EXTEN=
]=20
to see if their needs fit within the extended RADIUS data model.From Sectio=
n=20
3: 


   Recent extensions to the RADIUS data model such a=
s [EXTEN] make it
   possible to minimize the use of complex attributes.  New
   specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their need=
s fit within the extended
   RADIUS data model.

Proposed Resolution: Discuss







=

3D"i'm" EMAILING FOR THE GREAT=
ER GOOD
Join me

=

--_73b09e04-e9be-410b-b709-1f5ee1f52453_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 23:41:27 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_8907f3f2-4237-48ff-a215-48719ee1fd80_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Issue 311: IESG DISCUSS comments
Date: Wed, 2 Sep 2009 16:40:58 -0700
MIME-Version: 1.0

--_8907f3f2-4237-48ff-a215-48719ee1fd80_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


HTML clipboardIssue 311: IESG DISCUSS comments

Submitter name: Jari Arkko =20

Submitter email address: jari.arkko@piuha.net=20

Date first submitted:   May 7=2C 2009

Reference:
https://datatracker.ietf.org/idtracker/ballot/2883/

Document:=20
Design-Guidelines=20


Comment type: Technical=20

Priority: S =20

Section: Various

Rationale/Explanation of issue:

Jari Arkko:

Discuss [2009-05-07]:
Great doc! I will vote Yes on it=2C but I wanted to discuss two issues
first=2C one is a Discuss-level problem and the other one a Comment that
I'd like you to consider.
The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.

There are a couple of problems with this. First=2C if you really mean
to change the recommendation=2C then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.

Secondly=2C while I agree with the advice of going for 16 bits=2C the
document is silent on some of the issues involved in such a change=2C
such as:

- Does RADIUS dictionary software support the VSA format for 16 bits=2C 8
  bits=2C or both?

- How do you cleanly print or report VSAs when you do not know if the
  field size is 8 or 16 bits? I realize that this situation already
  exists since the format was never required to be followed=2C but
  your new recommendation makes a potential problem much more likely
  to appear. Previously=2C you could print something like Vendor =3D ACME=
=2C
  Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that.

- Can a vendor who moved from 8 bits to 16 bits deal with this?

Comment [2009-05-07]:
I do agree that for functionality FOO=2C both the functionality itself
and the MIB=2C RADIUS=2C etc. work should take place in the same standards
body. However=2C Section 3.1 could have said a couple of additional things
as well:

The issues of attribute space and choice of forum are distinct=3B there
is no reason why IETF couldn't use its own vendor code=2C for instance.

The section also does not mention one of the potential drawbacks of
SDO-driven development model: it is easy to come up with a number of
different solutions to the same generic problem=2C as opposed to finding
a common solution.

Ralph Droms:

Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte?  I ask bec=
ause
there has been confusion about this point in DHCP options and it might be g=
ood
to make the convention explicit.

Lars Eggert:

Comment [2009-04-20]:

Section 2.1.1=2C paragraph 2:
>    The Length field in the RADIUS packet header is defined in [RFC2865]
>    Section 3.  It is noted there that the maximum length of a RADIUS
>    packet is 4096 octets.  As a result=2C attribute designers SHOULD NOT
>    assume that a RADIUS implementation can successfully process RADIUS
>    packets larger than 4096 octets.

  You may want to point out that even with messages less than 4096 but
  larger than the PMTU=2C persistent IP fragmentation will be incurred=2C
  which makes communication much more brittle=2C and might even want to
  suggest that therefore RADIUS messages should be kept as small as
  possible. See RFC5405 Section 3.2.

Adrian Farrel:

Comment [2009-04-18]:
Trivial=2C but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a rea=
son
for this difference?

I wonder if the text in seciton 4 should be stronger. You have...

   This document does not require that the IANA update any existing
   registry or create any new registry=2C but includes information that
   affects the IANA=2C for example:

      * includes guidelines that recommend against allocation from the
        RADIUS standard attribute space in other SDO RADIUS Attribute
        specifications.

But=2C in fact=2C IANA are bound by the registry rules already laid down an=
d cannot
make allocations except following IETF process as defined by RFC 3575.

Russ Housley:

Comment [2009-04-20]:

  The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
  editorial suggestions.

  ID nits complains that reference [8] appears in Appendix B.6 but not
  in the References.

  The Introduction Section should be a non-normative section. However=2C
  Section 1.1 uses normative statements (RECOMMENDED and NOT
  RECOMMENDED) before those terms are defined in Section 1.3.

  The acronym AAA should be expanded.

  When referring to the appendixes=2C I think the draft should talk about
  appendixes=2C not about sections. For example=2C it should talk about
  Appendix A.5=2C not about Section A.5.

Alexey Melnikov:

Comment [2009-04-21]:
This is a fine document. Some minor comments:

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless=3B
      * Provisioning of services is not possible within an
        Access-Reject=3B
      * Distinction between authorization checks and user
        authentication=3B
      * Authentication and integrity protection of RADIUS packets=3B
      * The RADIUS protocol is a Request/Response protocol.
      * Packet length restriction.

Half of this list is comprised from full sentences=2C the other half is not=
. I
would appreciate if you can make this consistent=2C otherwise it
is difficult to read/understand.

Tim Polk:

Comment [2009-05-06]:
It might be valuable to supplement the current security considerations sect=
ion
with a discussion of issues that arise if SDOs do not follow the guidelines
presented here. For example=2C relying on MTU discovery to support transpor=
ting
large amounts of data could fail and result in denial of service=2C lost
accounting data=2C etc...

Robert Sparks:

Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.
Proposed Resolution: Discuss


 EMAILING FOR THE GREATER GOOD
Join me=

--_8907f3f2-4237-48ff-a215-48719ee1fd80_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






HTML clipboard=
Issue 311: IESG DISCUSS comments

Submitter name: Jari Arkko =3B 

Submitter email address: jari.arkko@piuha.net 

Date first submitted:  =3B May 7=2C 2009

Reference:
https://datatracker.ietf.org/idtracker/ballot/2883/

Document:=20
Design-Guidelines=20


Comment type: Technical 

Priority: S =3B 

Section: =3BVarious

Rationale/Explanation of issue:


Jari Arkko:

Discuss [2009-05-07]:
Great doc! I will vote Yes on it=2C but I wanted to discuss two issues
first=2C one is a Discuss-level problem and the other one a Comment that
I'd like you to consider.


The first issue is that Section 2.3 suggests 16-bit vendor space
attribute number fields to replace the existing 8-bit recommendation.

There are a couple of problems with this. First=2C if you really mean
to change the recommendation=2C then Updates: RFC 2865 header in the
beginning of the document would have been appropriate.

Secondly=2C while I agree with the advice of going for 16 bits=2C the
document is silent on some of the issues involved in such a change=2C
such as:

- Does RADIUS dictionary software support the VSA format for 16 bits=2C 8
  bits=2C or both?

- How do you cleanly print or report VSAs when you do not know if the
  field size is 8 or 16 bits? I realize that this situation already
  exists since the format was never required to be followed=2C but
  your new recommendation makes a potential problem much more likely
  to appear. Previously=2C you could print something like Vendor =3D ACME=
=2C
  Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that.

- Can a vendor who moved from 8 bits to 16 bits deal with this?

Comment [2009-05-07]:
I do agree that for functionality FOO=2C both the functionality itself
and the MIB=2C RADIUS=2C etc. work should take place in the same standards
body. However=2C Section 3.1 could have said a couple of additional things
as well:

The issues of attribute space and choice of forum are distinct=3B there
is no reason why IETF couldn't use its own vendor code=2C for instance.

The section also does not mention one of the potential drawbacks of
SDO-driven development model: it is easy to come up with a number of
different solutions to the same generic problem=2C as opposed to finding
a common solution.

Ralph Droms:

Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte?  I ask bec=
ause
there has been confusion about this point in DHCP options and it might be g=
ood
to make the convention explicit.

Lars Eggert:

Comment [2009-04-20]:

Section 2.1.1=2C paragraph 2:
>=3B    The Length field in the RADIUS packet header is defined in [RFC28=
65]
>=3B    Section 3.  It is noted there that the maximum length of a RADIUS
>=3B    packet is 4096 octets.  As a result=2C attribute designers SHOULD=
 NOT
>=3B    assume that a RADIUS implementation can successfully process RADI=
US
>=3B    packets larger than 4096 octets.

  You may want to point out that even with messages less than 4096 but
  larger than the PMTU=2C persistent IP fragmentation will be incurred=2C
  which makes communication much more brittle=2C and might even want to
  suggest that therefore RADIUS messages should be kept as small as
  possible. See RFC5405 Section 3.2.

Adrian Farrel:

Comment [2009-04-18]:
Trivial=2C but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a rea=
son
for this difference?

I wonder if the text in seciton 4 should be stronger. You have...

   This document does not require that the IANA update any existing
   registry or create any new registry=2C but includes information that
   affects the IANA=2C for example:

      * includes guidelines that recommend against allocation from the
        RADIUS standard attribute space in other SDO RADIUS Attribute
        specifications.

But=2C in fact=2C IANA are bound by the registry rules already laid down an=
d cannot
make allocations except following IETF process as defined by RFC 3575.

Russ Housley:

Comment [2009-04-20]:

  The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
  editorial suggestions.

  ID nits complains that reference [8] appears in Appendix B.6 but not
  in the References.

  The Introduction Section should be a non-normative section. However=2C
  Section 1.1 uses normative statements (RECOMMENDED and NOT
  RECOMMENDED) before those terms are defined in Section 1.3.

  The acronym AAA should be expanded.

  When referring to the appendixes=2C I think the draft should talk about
  appendixes=2C not about sections. For example=2C it should talk about
  Appendix A.5=2C not about Section A.5.

Alexey Melnikov:

Comment [2009-04-21]:
This is a fine document. Some minor comments:

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless=3B
      * Provisioning of services is not possible within an
        Access-Reject=3B
      * Distinction between authorization checks and user
        authentication=3B
      * Authentication and integrity protection of RADIUS packets=3B
      * The RADIUS protocol is a Request/Response protocol.
      * Packet length restriction.

Half of this list is comprised from full sentences=2C the other half is not=
. I
would appreciate if you can make this consistent=2C otherwise it
is difficult to read/understand.

Tim Polk:

Comment [2009-05-06]:
It might be valuable to supplement the current security considerations sect=
ion
with a discussion of issues that arise if SDOs do not follow the guidelines
presented here. For example=2C relying on MTU discovery to support transpor=
ting
large amounts of data could fail and result in denial of service=2C lost
accounting data=2C etc...

Robert Sparks:

Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.

Proposed Resolution: Discuss


=

--_8907f3f2-4237-48ff-a215-48719ee1fd80_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 22:54:08 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
Cc: 
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 15:53:26 -0700
Message-ID: <017f01ca2c20$345ee3d0$9d1cab70$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0180_01CA2BE5.88000BD0"
Thread-Index: AcorPDkhni+GKZxOQM2j7K4ZXIaStQA49fog
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_0180_01CA2BE5.88000BD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The RADEXT WG will be having a virtual interim meeting in early October.  

Why?

Potential dates include:

* Thursday, October 8
* Monday, October 12
* Tuesday, October 13
* Wednesday, October 14

To fill in your preferences for dates and times, please fill in the
following Doodle poll:
https://www.doodle.com/74uz2b233eu2vseg





	

 


------=_NextPart_000_0180_01CA2BE5.88000BD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



















The RADEXT WG will be having a =
virtual
interim meeting in early October.  



Why?



Potential dates include:



* Thursday, October 8

* Monday, October 12

* Tuesday, October 13

* Wednesday, October 14



To fill in your preferences for dates and times, please fill in the =
following
Doodle poll:

https://www.doodle.com/74uz2b233eu2vseg











=
3D"i'm" EMAILING FOR THE GREATER GOOD
Join me



 

  
 





 










------=_NextPart_000_0180_01CA2BE5.88000BD0--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 21:37:50 +0000
Date: Wed, 2 Sep 2009 21:37:11 +0000 (GMT)
From: David Mitton 
Reply-To: david@mitton.com
To: radiusext@ops.ietf.org
Message-ID: <1908411328.100621.1251927431963.JavaMail.mail@webmail05>
Subject: Re: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Thanks,
    I had the same question.  and FYI:  Oct 12th is Columbus Day, or 
   according to my calendar, Thanksgiving Day in Canada.

Dave.

Sep 2, 2009 12:38:30 PM, owner-radiusext@ops.ietf.org wrote:

Assumed time zone is PDT. 

> From: d.b.nelson@comcast.net
> To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org
> Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
> Date: Wed, 2 Sep 2009 12:10:45 -0400
> 
> > To fill in your preferences for dates and times, please fill
> > in the following Doodle poll:
> > https://www.doodle.com/74uz2b233eu2vseg
> 
> What is the assumed time zone for the times listed at the top of the poll
> matrix?
> 
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 16:34:43 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_a221acec-455c-432f-8c29-bd90c10de88b_"
From: Bernard Aboba 
To: "David B. Nelson" , "radiusext@ops.ietf.org" 
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 09:34:18 -0700
MIME-Version: 1.0

--_a221acec-455c-432f-8c29-bd90c10de88b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Assumed time zone is PDT.=20

> From: d.b.nelson@comcast.net
> To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org
> Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates=2C=
 Times
> Date: Wed=2C 2 Sep 2009 12:10:45 -0400
>=20
> > To fill in your preferences for dates and times=2C please fill
> > in the following Doodle poll:
> > https://www.doodle.com/74uz2b233eu2vseg
>=20
> What is the assumed time zone for the times listed at the top of the poll
> matrix?
>=20
>=20

--_a221acec-455c-432f-8c29-bd90c10de88b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Assumed time zone is PDT. 

>=3B From: d.b.nelson@comcast.net
&g=
t=3B To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org
>=3B Subj=
ect: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates=2C Times=

>=3B Date: Wed=2C 2 Sep 2009 12:10:45 -0400
>=3B 
>=3B >=
=3B To fill in your preferences for dates and times=2C please fill
>=
=3B >=3B in the following Doodle poll:
>=3B >=3B https://www.doodl=
e.com/74uz2b233eu2vseg
>=3B 
>=3B What is the assumed time zone f=
or the times listed at the top of the poll
>=3B matrix?
>=3B 
=
>=3B 

=

--_a221acec-455c-432f-8c29-bd90c10de88b_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 16:11:27 +0000
From: "Dave Nelson" 
To: "'Bernard Aboba'" , 
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 12:10:45 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcorPCmiZCVDDjxFQfy2rGgaBQotZgAq5Ztg

> To fill in your preferences for dates and times, please fill
> in the following Doodle poll:
> https://www.doodle.com/74uz2b233eu2vseg

What is the assumed time zone for the times listed at the top of the poll
matrix?



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Wed, 02 Sep 2009 08:33:16 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2BA7.E15232AA"
Subject: RE: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Wed, 2 Sep 2009 10:32:16 +0200
Message-ID: 
Thread-Topic: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Thread-Index: AcorO/ZEQLW3TAonRBCfrBaqTmN9ywAa9Deg
From: "Romascanu, Dan (Dan)" 
To: "Bernard Aboba" , 

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA2BA7.E15232AA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Bernard,
=20
What time zone?=20
=20
Dan
=20


________________________________

	From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
	Sent: Tuesday, September 01, 2009 10:38 PM
	To: radiusext@ops.ietf.org
	Subject: Action Requested: RADEXT WG Virtual Interim Meeting
Dates, Times
=09
=09
	The RADEXT WG will be having a virtual interim meeting in early
October.  Potential dates include:
=09
	* Thursday, October 8
	* Monday, October 12
	* Tuesday, October 13
	* Wednesday, October 14
=09
	To fill in your preferences for dates and times, please fill in
the following Doodle poll:
	https://www.doodle.com/74uz2b233eu2vseg
=09
=09
=09
=09
=09
=20
=09


------_=_NextPart_001_01CA2BA7.E15232AA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Bernard,


 


What time=20
zone? 


 


Dan


 



  

  

  From: owner-radiusext@ops.ietf.org=20
  [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20
  Aboba
Sent: Tuesday, September 01, 2009 10:38 =
PM
To:=20
  radiusext@ops.ietf.org
Subject: Action Requested: RADEXT WG =
Virtual=20
  Interim Meeting Dates, Times


  
The RADEXT WG will be having a virtual interim meeting in =
early=20
  October.  Potential dates include:

* Thursday, October =
8
*=20
  Monday, October 12
* Tuesday, October 13
* Wednesday, October=20
  14

To fill in your preferences for dates and times, please fill =
in the=20
  following Doodle=20
  poll:
https://www.doodle.com/74uz2b233eu2vseg





  
    
    
      
<=
/HTML>

------_=_NextPart_001_01CA2BA7.E15232AA--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 01 Sep 2009 19:40:11 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_73ada233-4a27-4935-9124-88c11b65da6e_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Call for Agenda items for RADEXT Virtual Interim Meeting
Date: Tue, 1 Sep 2009 12:40:02 -0700
MIME-Version: 1.0

--_73ada233-4a27-4935-9124-88c11b65da6e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a call for agenda items for the RADEXT Virtual Interim Meeting.  If=
 you'd like to get on the agenda=2C please send email to David or myself.=20



--_73ada233-4a27-4935-9124-88c11b65da6e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






This is a call for agenda items for the RADEXT Virtual Interim Meeting.&nbs=
p=3B If you'd like to get on the agenda=2C please send email to David or my=
self. 



=

--_73ada233-4a27-4935-9124-88c11b65da6e_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 


Envelope-to: radiusext-data0@psg.com
Delivery-date: Tue, 01 Sep 2009 19:38:54 +0000
Message-ID: 
Content-Type: multipart/alternative; boundary="_a642a527-345e-4fb0-803f-1bf85e389167_"
From: Bernard Aboba 
To: "radiusext@ops.ietf.org" 
Subject: Action Requested: RADEXT WG Virtual Interim Meeting Dates, Times
Date: Tue, 1 Sep 2009 12:38:07 -0700
MIME-Version: 1.0

--_a642a527-345e-4fb0-803f-1bf85e389167_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADEXT WG will be having a virtual interim meeting in early October.  P=
otential dates include:

* Thursday=2C October 8
* Monday=2C October 12
* Tuesday=2C October 13
* Wednesday=2C October 14

To fill in your preferences for dates and times=2C please fill in the follo=
wing Doodle poll:
https://www.doodle.com/74uz2b233eu2vseg






--_a642a527-345e-4fb0-803f-1bf85e389167_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






The RADEXT WG will be having a virtual interim meeting in early October.&nb=
sp=3B Potential dates include:

* Thursday=2C October 8
* Monday=
=2C October 12
* Tuesday=2C October 13
* Wednesday=2C October 14
<=
br>To fill in your preferences for dates and times=2C please fill in the fo=
llowing Doodle poll:
https://www.doodle.com/74uz2b233eu2vseg


=




=

--_a642a527-345e-4fb0-803f-1bf85e389167_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: