From owner-aaa-wg@merit.edu Thu Jan 2 05:13:29 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01929 for ; Thu, 2 Jan 2003 05:13:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1ECC091201; Thu, 2 Jan 2003 05:16:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA6839121C; Thu, 2 Jan 2003 05:16:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A41391201 for ; Thu, 2 Jan 2003 05:16:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A1B55DEED; Thu, 2 Jan 2003 05:15:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 2F7E85DD96 for ; Thu, 2 Jan 2003 05:15:51 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 854066A901; Thu, 2 Jan 2003 12:15:44 +0200 (EET) Message-ID: <3E14115B.707@kolumbus.fi> Date: Thu, 02 Jan 2003 12:15:55 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Ext-Venkata.Ghadiyaram@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Transport-10 review References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > We'll do a -12 revision to fix 3.4.1 and remove the Connection down events > in the DOWN and INITIAL states. A strawman is available at: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-12.txt Looks good after a brief review. (I didn't perform a full state machine verification, however.) Jari From owner-aaa-wg@merit.edu Thu Jan 2 21:44:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20642 for ; Thu, 2 Jan 2003 21:44:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8563C91224; Thu, 2 Jan 2003 21:47:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5548D91225; Thu, 2 Jan 2003 21:47:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B12291224 for ; Thu, 2 Jan 2003 21:46:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3204B5DE26; Thu, 2 Jan 2003 21:46:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id A66E55DDF9 for ; Thu, 2 Jan 2003 21:46:58 -0500 (EST) Received: (cpmta 8445 invoked from network); 2 Jan 2003 18:46:57 -0800 Received: from 69.3.41.106 (HELO DMITTON-IBMTP.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 2 Jan 2003 18:46:57 -0800 X-Sent: 3 Jan 2003 02:46:57 GMT Message-Id: <5.2.0.9.2.20030102213212.03983d90@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 02 Jan 2003 21:46:50 -0500 To: , From: David Mitton Subject: RE: [AAA-WG]: A question in NASREQ section 2.1 Cc: aaa-wg@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm asking all these questions, so you may perhaps answer yourself. - If the relay "knows" to send accounting messages to the accounting server and not the authentication server, then this accounting message is no different. - If the authentication server did not authenticate or authorize this session, (eg: returned a failure) then it need not receive anything further. - If the NAS decided it could not support an authenticated or authorized session,(eg: a AAA with success) then it should also issue an Session-Termination-Request (STR) to the Authentication Server to abort the session information at that server. [Section 2.3] As well as the Accounting EVENT_RECORD. Dave. At 1/3/2003 10:12 AM +0800, qing.roger.liu@nokia.com wrote: >Hi, > >As a service vendor may have a separated ACCT server, which have the same >diameter identity as the AUTH server. The relay will know the accounting >messages should be routed to ACCT server after capability negotiation with >the ACCT SERVER (the NASes do not need to know where is the servers, they >only need to set the destination host/realm AVPs properly). > >In this case, my question is that should the AUTH server be informed of >such a failure ? (Since this notification will be routed to ACCT server.) >If not, how to implement the following behavior of NAS, ACCT server? > >Thanks, >roger > > > >-----Original Message----- >From: ext David Mitton [mailto:david@mitton.com] >Sent: 24. December 2002 22:24 >To: Liu Qing.Roger (Nokia-RD/Beijing); aboba@internaut.com; >aaa-wg@merit.edu >Subject: Re: [AAA-WG]: A question in NASREQ section 2.1 > > >At 12/24/2002 05:26 PM +0800, qing.roger.liu@nokia.com wrote: > >In NASREQ section 2.1, > >"The failure to start a session SHOULD cause an Accounting EVENT_RECORD > >message." > > > >But regards to the following scenario, where will the Accounting > >EVENT_RECORD message be addressed to? > > > > +--------+ +-------+ +-------------+ > > | NAS |--------| Relay |--------| Auth Server | > > +--------+ +---+---+ +-------------+ > > | > > | > > +------+------+ > > | Acct Server | > > +-------------+ > > > >Best regards, > >roger > >Where would a successful Accounting message go? >What criteria is the Relay using to split the streams? >How would the source know that? >Who configured this? > >Dave. From owner-aaa-wg@merit.edu Thu Jan 2 22:36:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21684 for ; Thu, 2 Jan 2003 22:36:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF18B91222; Thu, 2 Jan 2003 22:39:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EF9491225; Thu, 2 Jan 2003 22:39:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E95491222 for ; Thu, 2 Jan 2003 22:39:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1C0C5DE5E; Thu, 2 Jan 2003 22:39:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 4509C5DDF3 for ; Thu, 2 Jan 2003 22:39:16 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h033f7t22844 for ; Fri, 3 Jan 2003 05:41:07 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 Jan 2003 05:37:07 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Jan 2003 05:37:06 +0200 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 3 Jan 2003 11:32:20 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: A question in NASREQ section 2.1 Date: Fri, 3 Jan 2003 11:32:20 +0800 Message-ID: Thread-Topic: [AAA-WG]: A question in NASREQ section 2.1 Thread-Index: AcKy0w6B1pC0wNTDT6KyFNJhX52KvAAAxtGQ From: To: , Cc: X-OriginalArrivalTime: 03 Jan 2003 03:32:20.0614 (UTC) FILETIME=[B8FE2A60:01C2B2D8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA21684 Thanks Dave, I suppose you mentioned one choice for the NAS that it could terminate the session if it failed to start a NASREQ session context. However I wonder if the NAS will go to extreme to do so, as neither NASREQ or [BASE] have mentioned what actions shall ACCT server/NAS take after an EVENT_RECORD request/answer message is received. And this is the reason I invite Aboba to explain possible further behavior of NAS and ACCT server handling such a failure. Best regards, roger -----Original Message----- From: ext David Mitton [mailto:david@mitton.com] Sent: 03. January 2003 10:47 To: Liu Qing.Roger (Nokia-RD/Beijing); aboba@internaut.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: A question in NASREQ section 2.1 I'm asking all these questions, so you may perhaps answer yourself. - If the relay "knows" to send accounting messages to the accounting server and not the authentication server, then this accounting message is no different. - If the authentication server did not authenticate or authorize this session, (eg: returned a failure) then it need not receive anything further. - If the NAS decided it could not support an authenticated or authorized session,(eg: a AAA with success) then it should also issue an Session-Termination-Request (STR) to the Authentication Server to abort the session information at that server. [Section 2.3] As well as the Accounting EVENT_RECORD. Dave. At 1/3/2003 10:12 AM +0800, qing.roger.liu@nokia.com wrote: >Hi, > >As a service vendor may have a separated ACCT server, which have the same >diameter identity as the AUTH server. The relay will know the accounting >messages should be routed to ACCT server after capability negotiation with >the ACCT SERVER (the NASes do not need to know where is the servers, they >only need to set the destination host/realm AVPs properly). > >In this case, my question is that should the AUTH server be informed of >such a failure ? (Since this notification will be routed to ACCT server.) >If not, how to implement the following behavior of NAS, ACCT server? > >Thanks, >roger > > > >-----Original Message----- >From: ext David Mitton [mailto:david@mitton.com] >Sent: 24. December 2002 22:24 >To: Liu Qing.Roger (Nokia-RD/Beijing); aboba@internaut.com; >aaa-wg@merit.edu >Subject: Re: [AAA-WG]: A question in NASREQ section 2.1 > > >At 12/24/2002 05:26 PM +0800, qing.roger.liu@nokia.com wrote: > >In NASREQ section 2.1, > >"The failure to start a session SHOULD cause an Accounting EVENT_RECORD > >message." > > > >But regards to the following scenario, where will the Accounting > >EVENT_RECORD message be addressed to? > > > > +--------+ +-------+ +-------------+ > > | NAS |--------| Relay |--------| Auth Server | > > +--------+ +---+---+ +-------------+ > > | > > | > > +------+------+ > > | Acct Server | > > +-------------+ > > > >Best regards, > >roger > >Where would a successful Accounting message go? >What criteria is the Relay using to split the streams? >How would the source know that? >Who configured this? > >Dave. From owner-aaa-wg@merit.edu Fri Jan 3 00:39:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23255 for ; Fri, 3 Jan 2003 00:39:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C994A9121F; Fri, 3 Jan 2003 00:42:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F89091225; Fri, 3 Jan 2003 00:42:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B38B9121F for ; Fri, 3 Jan 2003 00:42:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 73A425DE0A; Fri, 3 Jan 2003 00:42:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id 3146E5DD8D for ; Fri, 3 Jan 2003 00:42:04 -0500 (EST) Received: (cpmta 6433 invoked from network); 2 Jan 2003 21:42:03 -0800 Received: from 24.147.218.40 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.65) with SMTP; 2 Jan 2003 21:42:03 -0800 X-Sent: 3 Jan 2003 05:42:03 GMT Message-Id: <5.2.0.9.2.20030103003811.049bcb40@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 03 Jan 2003 00:44:30 -0500 To: , From: David Mitton Subject: RE: [AAA-WG]: A question in NASREQ section 2.1 Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 1/3/2003 11:32 AM +0800, qing.roger.liu@nokia.com wrote: >Thanks Dave, > >I suppose you mentioned one choice for the NAS that it could terminate the >session if it failed to start a NASREQ session context. However I wonder >if the NAS will go to extreme to do so, This is not extreme. If a NAS cannot support a service it MUST terminate it, even if it's authenticated or authorized. Believe me, NASes do it with RADIUS all the time. > as neither NASREQ or [BASE] have mentioned what actions shall ACCT > server/NAS take after an EVENT_RECORD request/answer message is received. The drafts do not discuss every possible action. There are no external actions for an accounting server to take. It should record the event and any implication of that is implementation dependent. The purpose of the event record is obvious. ISPs want a record of every attempted session and the result. Failed attempts can offer information about user mistakes, or hackers rattling the door knobs. It's also extremely useful when debugging. The Accounting records should show these. Dave. >And this is the reason I invite Aboba to explain possible further behavior >of NAS and ACCT server handling such a failure. > >Best regards, >roger > > >-----Original Message----- >From: ext David Mitton [mailto:david@mitton.com] >Sent: 03. January 2003 10:47 >To: Liu Qing.Roger (Nokia-RD/Beijing); aboba@internaut.com >Cc: aaa-wg@merit.edu >Subject: RE: [AAA-WG]: A question in NASREQ section 2.1 > > >I'm asking all these questions, so you may perhaps answer yourself. > >- If the relay "knows" to send accounting messages to the accounting server >and not the authentication server, then this accounting message is no >different. > >- If the authentication server did not authenticate or authorize this >session, (eg: returned a failure) then it need not receive anything further. > >- If the NAS decided it could not support an authenticated or authorized >session,(eg: a AAA with success) then it should also issue an >Session-Termination-Request (STR) to the Authentication Server to abort the >session information at that server. [Section 2.3] As well as the >Accounting EVENT_RECORD. > >Dave. > >At 1/3/2003 10:12 AM +0800, qing.roger.liu@nokia.com wrote: > >Hi, > > > >As a service vendor may have a separated ACCT server, which have the same > >diameter identity as the AUTH server. The relay will know the accounting > >messages should be routed to ACCT server after capability negotiation with > >the ACCT SERVER (the NASes do not need to know where is the servers, they > >only need to set the destination host/realm AVPs properly). > > > >In this case, my question is that should the AUTH server be informed of > >such a failure ? (Since this notification will be routed to ACCT server.) > >If not, how to implement the following behavior of NAS, ACCT server? > > > >Thanks, > >roger > > > > > > > >-----Original Message----- > >From: ext David Mitton [mailto:david@mitton.com] > >Sent: 24. December 2002 22:24 > >To: Liu Qing.Roger (Nokia-RD/Beijing); aboba@internaut.com; > >aaa-wg@merit.edu > >Subject: Re: [AAA-WG]: A question in NASREQ section 2.1 > > > > > >At 12/24/2002 05:26 PM +0800, qing.roger.liu@nokia.com wrote: > > >In NASREQ section 2.1, > > >"The failure to start a session SHOULD cause an Accounting EVENT_RECORD > > >message." > > > > > >But regards to the following scenario, where will the Accounting > > >EVENT_RECORD message be addressed to? > > > > > > +--------+ +-------+ +-------------+ > > > | NAS |--------| Relay |--------| Auth Server | > > > +--------+ +---+---+ +-------------+ > > > | > > > | > > > +------+------+ > > > | Acct Server | > > > +-------------+ > > > > > >Best regards, > > >roger > > > >Where would a successful Accounting message go? > >What criteria is the Relay using to split the streams? > >How would the source know that? > >Who configured this? > > > >Dave. From owner-aaa-wg@merit.edu Fri Jan 3 01:58:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24065 for ; Fri, 3 Jan 2003 01:58:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 131A991225; Fri, 3 Jan 2003 02:01:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8147691226; Fri, 3 Jan 2003 02:01:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 676B091225 for ; Fri, 3 Jan 2003 02:01:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1DCE5DD9B; Fri, 3 Jan 2003 02:00:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6DDC55DD8D for ; Fri, 3 Jan 2003 02:00:55 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h035pxU21164; Thu, 2 Jan 2003 21:51:59 -0800 Date: Thu, 2 Jan 2003 21:51:58 -0800 (PST) From: Bernard Aboba To: David Mitton Cc: qing.roger.liu@nokia.com, Subject: RE: [AAA-WG]: A question in NASREQ section 2.1 In-Reply-To: <5.2.0.9.2.20030103003811.049bcb40@getmail.mitton.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > >I suppose you mentioned one choice for the NAS that it could terminate the > >session if it failed to start a NASREQ session context. However I wonder > >if the NAS will go to extreme to do so, > > This is not extreme. If a NAS cannot support a service it MUST terminate > it, even if it's authenticated or authorized. Believe me, NASes do it with > RADIUS all the time. That's preferrable to attempting to provide a different service than what was requested -- which happens sometimes with RADIUS (I've seen RADIUS implementations that ignored Filter-Id attributes they didn't understand, instead of dropping the call). > The purpose of the event record is obvious. ISPs want a record of every > attempted session and the result. Failed attempts can offer information > about user mistakes, or hackers rattling the door knobs. It's also > extremely useful when debugging. The Accounting records should show these. One of the most annoying things about RADIUS is that you don't see Accounting records for failed calls -- just the information that you want in the early phases of a deployment, particularly when interoperability issues may still be shaking out -- as they are with 802.11 implementations, for example. In the early phases of a rollout, I like to be able to access *all* of the available information -- and to wring as much information out of the failed call records as is available, until the failure rate is low enough to consider the service operational. From owner-aaa-wg@merit.edu Fri Jan 3 02:11:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04078 for ; Fri, 3 Jan 2003 02:11:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 28A6891226; Fri, 3 Jan 2003 02:14:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEA7491227; Fri, 3 Jan 2003 02:14:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2B6F91226 for ; Fri, 3 Jan 2003 02:14:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D27C25DE26; Fri, 3 Jan 2003 02:14:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 57AC75DD8D for ; Fri, 3 Jan 2003 02:14:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0365Yk21934 for ; Thu, 2 Jan 2003 22:05:34 -0800 Date: Thu, 2 Jan 2003 22:05:34 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Conclusion of AAA WG last call on NASREQ In-Reply-To: <5.2.0.9.2.20030103003811.049bcb40@getmail.mitton.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call has concluded on draft-ietf-aaa-diameter-nasreq-10.txt, which is being considered for advancement as an IETF Proposed Standard. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt Two issues were raised in last call (389, 395), and are available for inspection at: http://www.drizzle.com/~aboba/AAA/issues.html As NASREQ is a dependency of 3GPP2, and we are already late, getting this document ready for IESG review is an important goal for the month of January 2003. The goal is to start 2003 by getting NASREQ into the hands of the IESG within a few weeks. Here's the game plan: a. Address the AAA WG last call comments, as well as IESG NITs. b. Post a strawman -11 document for review. c. Incorporate any other last minute comments (if you haven't done your review now, time is running out...) d. Get a -11 draft out on the IETF archive and ready for IESG review by January 17, 2003 (in time for the IETF/3GPP meeting). From mailnull@www1.ietf.org Tue Jan 14 15:22:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10302 for ; Tue, 14 Jan 2003 15:22:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKapx29227 for aaa-archive@odin.ietf.org; Tue, 14 Jan 2003 15:36:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKapJ29224 for ; Tue, 14 Jan 2003 15:36:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10267 for ; Tue, 14 Jan 2003 15:22:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKaoJ29220 for ; Tue, 14 Jan 2003 15:36:50 -0500 Date: Tue, 14 Jan 2003 15:36:50 -0500 Message-ID: <20030114203650.29218.60962.Mailman@www1.ietf.org> Subject: Welcome to the "Aaa" mailing list From: aaa-request@ietf.org To: aaa-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Welcome to the Aaa@ietf.org mailing list! To post to this list, send your email to: aaa@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/aaa ************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ************************************************************************** If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www1.ietf.org/mailman/options/aaa/aaa-web-archive%40ietf.org You can also make such adjustments via email by sending a message to: Aaa-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: wumate If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From mailnull@www1.ietf.org Tue Jan 14 15:26:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10444 for ; Tue, 14 Jan 2003 15:26:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKf2730281 for aaa-archive@odin.ietf.org; Tue, 14 Jan 2003 15:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKf2J30267 for ; Tue, 14 Jan 2003 15:41:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10433 for ; Tue, 14 Jan 2003 15:26:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKf1J30251 for ; Tue, 14 Jan 2003 15:41:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKeCJ30187 for ; Tue, 14 Jan 2003 15:40:12 -0500 Received: from cnri.reston.va.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10373 for ; Tue, 14 Jan 2003 15:25:24 -0500 (EST) Received: from hubris.cnri.reston.va.us (cnri-7-65.cnri.reston.va.us [132.151.7.65]) by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h0EKSj824763 for ; Tue, 14 Jan 2003 15:28:45 -0500 (EST) Message-Id: <5.0.0.25.2.20030114152553.0251bc68@mailbox.cnri.reston.va.us> X-Sender: gcunning@mailbox.cnri.reston.va.us X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 14 Jan 2003 15:27:33 -0500 To: aaa@ietf.org From: Greg Cunningham Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Aaa] Test Message #1 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , The AAA WG mailing list is being moved to the ietf. This is a test message to check the archives. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From mailnull@www1.ietf.org Tue Jan 14 17:36:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14256 for ; Tue, 14 Jan 2003 17:36:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EMocM08630 for aaa-archive@odin.ietf.org; Tue, 14 Jan 2003 17:50:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMobJ08627 for ; Tue, 14 Jan 2003 17:50:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14250 for ; Tue, 14 Jan 2003 17:35:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMoCJ08606; Tue, 14 Jan 2003 17:50:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMguJ08409 for ; Tue, 14 Jan 2003 17:42:56 -0500 Received: from internaut.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14018 for ; Tue, 14 Jan 2003 17:28:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0ELLVe12163 for ; Tue, 14 Jan 2003 13:21:31 -0800 Date: Tue, 14 Jan 2003 13:21:31 -0800 (PST) From: Bernard Aboba To: aaa@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Aaa] Potential transition of AAA WG mailing list to ietf.org Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Due to a variety of nagging problems in maintenance of the current AAA WG mailing list at MERIT, we are considering moving the list over to ietf.org. There are some pros and cons: Pros: The ietf.org list would use mailman, which enables postings from outsiders and is less likely to randomly unsubscribe people. Cons: The old archives will be available via FTP, but not via the Web anymore. We will however have a new Web archive. If anyone has an opinion on the switchover, please post to the list. WE are not irretrievably committed either way at the moment, but that won't be true for a lot longer. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Tue Jan 14 17:48:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14642 for ; Tue, 14 Jan 2003 17:48:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMoCJ08606; Tue, 14 Jan 2003 17:50:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMguJ08409 for ; Tue, 14 Jan 2003 17:42:56 -0500 Received: from internaut.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14018 for ; Tue, 14 Jan 2003 17:28:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0ELLVe12163 for ; Tue, 14 Jan 2003 13:21:31 -0800 Date: Tue, 14 Jan 2003 13:21:31 -0800 (PST) From: Bernard Aboba To: aaa@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Aaa] Potential transition of AAA WG mailing list to ietf.org Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Due to a variety of nagging problems in maintenance of the current AAA WG mailing list at MERIT, we are considering moving the list over to ietf.org. There are some pros and cons: Pros: The ietf.org list would use mailman, which enables postings from outsiders and is less likely to randomly unsubscribe people. Cons: The old archives will be available via FTP, but not via the Web anymore. We will however have a new Web archive. If anyone has an opinion on the switchover, please post to the list. WE are not irretrievably committed either way at the moment, but that won't be true for a lot longer. _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaatest@ops.ietf.org Tue Jan 14 19:11:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16751 for ; Tue, 14 Jan 2003 19:11:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Yb1i-000FEm-00 for aaatest-data@psg.com; Tue, 14 Jan 2003 16:03:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Yb1g-000FES-00 for aaatest@ops.ietf.org; Tue, 14 Jan 2003 16:03:24 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Yb1g-000NPU-00 for aaatest@ops.ietf.org; Tue, 14 Jan 2003 16:03:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaatest@ops.ietf.org Subject: test Message-Id: Date: Tue, 14 Jan 2003 16:03:24 -0800 X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-aaatest@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit please ignore. do NOT reply to this message. randy From mailnull@www1.ietf.org Tue Jan 14 22:59:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21678 for ; Tue, 14 Jan 2003 22:59:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F4EHj28882 for aaa-archive@odin.ietf.org; Tue, 14 Jan 2003 23:14:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4EHJ28879 for ; Tue, 14 Jan 2003 23:14:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21675 for ; Tue, 14 Jan 2003 22:59:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4DuJ28868; Tue, 14 Jan 2003 23:13:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4A7J28777 for ; Tue, 14 Jan 2003 23:10:07 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21627 for ; Tue, 14 Jan 2003 22:55:10 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0F3vX017719 for ; Wed, 15 Jan 2003 05:57:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 05:58:29 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 05:58:29 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 05:58:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Aaa] Potential transition of AAA WG mailing list to ietf.org Date: Wed, 15 Jan 2003 05:58:26 +0200 Message-ID: Thread-Topic: [Aaa] Potential transition of AAA WG mailing list to ietf.org Thread-Index: AcK8Hda2K0qj9B2/RuS4/SCp8xJfBAALGQmg To: , X-OriginalArrivalTime: 15 Jan 2003 03:58:29.0037 (UTC) FILETIME=[5CCD85D0:01C2BC4A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F4A7J28778 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Bernard, First off, I have no big opinion, but: > Pros: > > The ietf.org list would use mailman, which enables postings from > outsiders [cut] This is not necessarily a pro - the AAA mailing list has been relatively free of spam ... John _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Tue Jan 14 23:04:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21781 for ; Tue, 14 Jan 2003 23:04:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4DuJ28868; Tue, 14 Jan 2003 23:13:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4A7J28777 for ; Tue, 14 Jan 2003 23:10:07 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21627 for ; Tue, 14 Jan 2003 22:55:10 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0F3vX017719 for ; Wed, 15 Jan 2003 05:57:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 05:58:29 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 05:58:29 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 05:58:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Aaa] Potential transition of AAA WG mailing list to ietf.org Date: Wed, 15 Jan 2003 05:58:26 +0200 Message-ID: Thread-Topic: [Aaa] Potential transition of AAA WG mailing list to ietf.org Thread-Index: AcK8Hda2K0qj9B2/RuS4/SCp8xJfBAALGQmg To: , X-OriginalArrivalTime: 15 Jan 2003 03:58:29.0037 (UTC) FILETIME=[5CCD85D0:01C2BC4A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F4A7J28778 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bernard, First off, I have no big opinion, but: > Pros: > > The ietf.org list would use mailman, which enables postings from > outsiders [cut] This is not necessarily a pro - the AAA mailing list has been relatively free of spam ... John _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Jan 15 02:48:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18962 for ; Wed, 15 Jan 2003 02:48:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86D2F912A6; Wed, 15 Jan 2003 02:51:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52591912A7; Wed, 15 Jan 2003 02:51:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36312912A6 for ; Wed, 15 Jan 2003 02:51:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22AC45DFE0; Wed, 15 Jan 2003 02:51:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by segue.merit.edu (Postfix) with ESMTP id 4E7075DF8F for ; Wed, 15 Jan 2003 02:51:08 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA27674 for ; Wed, 15 Jan 2003 08:51:07 +0100 (MET) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA26881 for ; Wed, 15 Jan 2003 08:51:06 +0100 (MET) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 08:51:07 +0100 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6DBF09C@mchh161e.mch4.siemens.de> From: Daser Martin ICM N PG U ID A 3 To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: test only Date: Wed, 15 Jan 2003 08:51:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk do NOT reply From mailnull@www1.ietf.org Wed Jan 15 03:05:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19322 for ; Wed, 15 Jan 2003 03:05:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F8K1d20907 for aaa-archive@odin.ietf.org; Wed, 15 Jan 2003 03:20:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8K0J20904 for ; Wed, 15 Jan 2003 03:20:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19290 for ; Wed, 15 Jan 2003 03:04:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8JdJ20893; Wed, 15 Jan 2003 03:19:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8EsJ20706 for ; Wed, 15 Jan 2003 03:14:54 -0500 Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19148 for ; Wed, 15 Jan 2003 02:59:51 -0500 (EST) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id IAA01767; Wed, 15 Jan 2003 08:03:11 GMT Received: from putney.vfl.vodafone (putney [10.33.112.118]) by mailguard4 (4.6.1.123) with ESMTP id for ; Wed, 15 Jan 2003 07:58:39 GMT Received: from ukwmxc02.vf-uk.internal.vodafone.com ([10.33.126.170]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YL9A3CKA; Wed, 15 Jan 2003 08:02:55 -0000 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 Jan 2003 08:02:05 +0000 Received: from ukwmxm01.vf-uk.internal.vodafone.com ([10.33.126.162]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 Jan 2003 08:02:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [Aaa] Potential transition of AAA WG mailing list to ietf.org Date: Wed, 15 Jan 2003 08:02:05 -0000 Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B7128100E12@UKWMXM01> Thread-Topic: [Aaa] Potential transition of AAA WG mailing list to ietf.org Thread-Index: AcK8Hda2K0qj9B2/RuS4/SCp8xJfBAALGQmgAAhaiAA= From: "Russell, Nick, CND Tech Dev, VF UK" To: X-OriginalArrivalTime: 15 Jan 2003 08:02:05.0188 (UTC) FILETIME=[64B52C40:01C2BC6C] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F8EsJ20707 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I agree with John, an open mailing list is not a pro. The main IETF list when I was on it received about 50% spam and 50% actual postings. Twas a bit of a pain to sift through it all. If we do have to move over to using the IETF listserv, is there any possibility of using something like Spam Assassin (http://spamassassin.org/) to filter out at least some of the rubbish? I guess it won't filter out people who insist on sending out their Résumés/CVs to us, but maybe it might catch at least advertisements and porn. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 15 January 2003 3:58am > To: aboba@internaut.com; aaa@ietf.org > Subject: RE: [Aaa] Potential transition of AAA WG mailing list to > ietf.org > > > Hi Bernard, > > First off, I have no big opinion, but: > > > Pros: > > > > The ietf.org list would use mailman, which enables postings from > > outsiders [cut] > > This is not necessarily a pro - the AAA mailing list has been > relatively free of spam ... > > John > _______________________________________________ > Aaa mailing list > Aaa@ietf.org > https://www1.ietf.org/mailman/listinfo/aaa > _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Jan 15 03:11:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19410 for ; Wed, 15 Jan 2003 03:11:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8JdJ20893; Wed, 15 Jan 2003 03:19:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F8EsJ20706 for ; Wed, 15 Jan 2003 03:14:54 -0500 Received: from igate2.vodafone.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19148 for ; Wed, 15 Jan 2003 02:59:51 -0500 (EST) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id IAA01767; Wed, 15 Jan 2003 08:03:11 GMT Received: from putney.vfl.vodafone (putney [10.33.112.118]) by mailguard4 (4.6.1.123) with ESMTP id for ; Wed, 15 Jan 2003 07:58:39 GMT Received: from ukwmxc02.vf-uk.internal.vodafone.com ([10.33.126.170]) by putney.vfl.vodafone with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YL9A3CKA; Wed, 15 Jan 2003 08:02:55 -0000 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 Jan 2003 08:02:05 +0000 Received: from ukwmxm01.vf-uk.internal.vodafone.com ([10.33.126.162]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 Jan 2003 08:02:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [Aaa] Potential transition of AAA WG mailing list to ietf.org Date: Wed, 15 Jan 2003 08:02:05 -0000 Message-ID: <6FC554FA1F33BE4C9AC844FC3B3B7128100E12@UKWMXM01> Thread-Topic: [Aaa] Potential transition of AAA WG mailing list to ietf.org Thread-Index: AcK8Hda2K0qj9B2/RuS4/SCp8xJfBAALGQmgAAhaiAA= From: "Russell, Nick, CND Tech Dev, VF UK" To: X-OriginalArrivalTime: 15 Jan 2003 08:02:05.0188 (UTC) FILETIME=[64B52C40:01C2BC6C] MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0F8EsJ20707 Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree with John, an open mailing list is not a pro. The main IETF list when I was on it received about 50% spam and 50% actual postings. Twas a bit of a pain to sift through it all. If we do have to move over to using the IETF listserv, is there any possibility of using something like Spam Assassin (http://spamassassin.org/) to filter out at least some of the rubbish? I guess it won't filter out people who insist on sending out their Résumés/CVs to us, but maybe it might catch at least advertisements and porn. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 15 January 2003 3:58am > To: aboba@internaut.com; aaa@ietf.org > Subject: RE: [Aaa] Potential transition of AAA WG mailing list to > ietf.org > > > Hi Bernard, > > First off, I have no big opinion, but: > > > Pros: > > > > The ietf.org list would use mailman, which enables postings from > > outsiders [cut] > > This is not necessarily a pro - the AAA mailing list has been > relatively free of spam ... > > John > _______________________________________________ > Aaa mailing list > Aaa@ietf.org > https://www1.ietf.org/mailman/listinfo/aaa > _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From mailnull@www1.ietf.org Wed Jan 15 11:18:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01760 for ; Wed, 15 Jan 2003 11:18:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGXDk22508 for aaa-archive@odin.ietf.org; Wed, 15 Jan 2003 11:33:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGXCJ22505 for ; Wed, 15 Jan 2003 11:33:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01737 for ; Wed, 15 Jan 2003 11:18:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGWkJ22469; Wed, 15 Jan 2003 11:32:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGR8J22070 for ; Wed, 15 Jan 2003 11:27:08 -0500 Received: from segue.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01449 for ; Wed, 15 Jan 2003 11:11:57 -0500 (EST) Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id 7AD7A5DDE1; Wed, 15 Jan 2003 11:15:15 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id LAA25604; Wed, 15 Jan 2003 11:15:15 -0500 (EST) Date: Wed, 15 Jan 2003 11:15:15 -0500 From: William Bulley To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa@ietf.org Subject: Re: [Aaa] Potential transition of AAA WG mailing list to ietf.org Message-ID: <20030115111514.C25056@web1.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , According to john.loughney@nokia.com: > > Hi Bernard, > > First off, I have no big opinion, but: > > > Pros: > > > > The ietf.org list would use mailman, which enables postings from > > outsiders [cut] > > This is not necessarily a pro - the AAA mailing list has been > relatively free of spam ... I didn't understand the part about the "randomly unsubscribe people" and the "nagging problems". Merit has assigned me to "maintain" this list and if there are problems, someone should at least inform me of them, yes? I am unfamiliar with mailman but have started to read the mailman home page. Merit may have problems if the license is too strict, but I haven't gotten that for yet. Are there any problems with Merit's archive? Changes/improvements therein are possible. Do folks in general want "postings from outsiders"? I, too, value the "closed" nature of the list since it does keep the SPAM away. Regards, web... -- William Bulley Email: web@merit.edu Merit Network Inc. Ann Arbor, Michigan _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From aaa-admin@ietf.org Wed Jan 15 11:28:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02196 for ; Wed, 15 Jan 2003 11:28:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGWkJ22469; Wed, 15 Jan 2003 11:32:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGR8J22070 for ; Wed, 15 Jan 2003 11:27:08 -0500 Received: from segue.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01449 for ; Wed, 15 Jan 2003 11:11:57 -0500 (EST) Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id 7AD7A5DDE1; Wed, 15 Jan 2003 11:15:15 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id LAA25604; Wed, 15 Jan 2003 11:15:15 -0500 (EST) Date: Wed, 15 Jan 2003 11:15:15 -0500 From: William Bulley To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa@ietf.org Subject: Re: [Aaa] Potential transition of AAA WG mailing list to ietf.org Message-ID: <20030115111514.C25056@web1.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , According to john.loughney@nokia.com: > > Hi Bernard, > > First off, I have no big opinion, but: > > > Pros: > > > > The ietf.org list would use mailman, which enables postings from > > outsiders [cut] > > This is not necessarily a pro - the AAA mailing list has been > relatively free of spam ... I didn't understand the part about the "randomly unsubscribe people" and the "nagging problems". Merit has assigned me to "maintain" this list and if there are problems, someone should at least inform me of them, yes? I am unfamiliar with mailman but have started to read the mailman home page. Merit may have problems if the license is too strict, but I haven't gotten that for yet. Are there any problems with Merit's archive? Changes/improvements therein are possible. Do folks in general want "postings from outsiders"? I, too, value the "closed" nature of the list since it does keep the SPAM away. Regards, web... -- William Bulley Email: web@merit.edu Merit Network Inc. Ann Arbor, Michigan _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Tue Jan 21 17:39:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14224 for ; Tue, 21 Jan 2003 17:39:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6903991366; Tue, 21 Jan 2003 17:41:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 095FE9138C; Tue, 21 Jan 2003 17:41:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3101991366 for ; Tue, 21 Jan 2003 17:41:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E8055E05A; Tue, 21 Jan 2003 17:41:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 947DF5DE65 for ; Tue, 21 Jan 2003 17:41:49 -0500 (EST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0LMfm707907 for ; Tue, 21 Jan 2003 17:41:48 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 17:41:48 -0500 Message-ID: <1B8C2E08B21B8743A2B3AED07407DA76035E14@nj7460exch002u.ho.lucent.com> From: "Zeltsan, Zachary (Zachary)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Status of the Java API Date: Tue, 21 Jan 2003 17:41:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk The Java API was a part of the darft Diameter API version 01. There was a discussion on this list on standardizing Diameter Java API through Java Specification Request (JSR) under Java Community Process (JCP), then the specifications on the Java API were excluded from the following versions of the draft. Does anyone know if there is any work being done on the Java API? With thanks, Zachary Zeltsan From owner-aaa-wg@merit.edu Wed Jan 22 10:28:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27843 for ; Wed, 22 Jan 2003 10:28:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41C8E912F7; Wed, 22 Jan 2003 10:31:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC277912F8; Wed, 22 Jan 2003 10:31:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 829CD912F7 for ; Wed, 22 Jan 2003 10:31:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 837365DE9E; Wed, 22 Jan 2003 10:31:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0A8905DE8A for ; Wed, 22 Jan 2003 10:31:02 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0MEKTS11318 for ; Wed, 22 Jan 2003 06:20:29 -0800 Date: Wed, 22 Jan 2003 06:20:29 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-ietf-aaa-diameter preview (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 22 Jan 2003 10:30:01 +0200 From: john.loughney@nokia.com To: aaa-editors@internaut.com Cc: randy@psg.com, bwijnen@lucent.com Subject: draft-ietf-aaa-diameter preview Hi all, I have updated the Diameter base spec, I want to a read of it before submitting, but the current version can be found here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-17.txt The plan is to submit it shortly, so that Randy can put it on the IESG conference call agenda tomorrow. thanks, John From owner-aaa-wg@merit.edu Wed Jan 22 10:54:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28804 for ; Wed, 22 Jan 2003 10:54:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D27049137C; Wed, 22 Jan 2003 10:58:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A38B59137D; Wed, 22 Jan 2003 10:58:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE7429137C for ; Wed, 22 Jan 2003 10:57:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97BB35DE8A; Wed, 22 Jan 2003 10:57:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 234D85DE37 for ; Wed, 22 Jan 2003 10:57:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0MElQi12830 for ; Wed, 22 Jan 2003 06:47:26 -0800 Date: Wed, 22 Jan 2003 06:47:26 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RFC 2869bis to IETF Last Call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk In order to have RFC 2869bis published as an RFC in time for citation by IEEE 802.1aa, it needs to enter IETF last call approximately 4-5 months before publication is required. In order not to delay IEEE 802.1aa, I have asked for the draft, which is available below, to go to IETF last call. Since this is the last opportunity for people to read and comment on it, it's important for those interested in the subject of RADIUS/EAP to do a read through and ensure that it is satisfactory. Comments can be sent to the EAP WG mailing list (eap@frascone.com) and to the authors, using the format described at: http://www.drizzle.com/~aboba/EAP/eapissues.html The draft itself is available at: http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-06.txt From owner-aaa-wg@merit.edu Wed Jan 22 11:15:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29509 for ; Wed, 22 Jan 2003 11:15:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0EAF91385; Wed, 22 Jan 2003 11:18:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DDCE9138A; Wed, 22 Jan 2003 11:18:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8CFF91386 for ; Wed, 22 Jan 2003 11:18:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id C798F5DEAF; Wed, 22 Jan 2003 11:18:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id DEEE75DEAB for ; Wed, 22 Jan 2003 11:18:16 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0MGHG024159 for ; Wed, 22 Jan 2003 18:17:16 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 22 Jan 2003 18:18:15 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 18:18:15 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 18:18:15 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 18:18:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: draft-ietf-aaa-diameter preview (fwd) Date: Wed, 22 Jan 2003 18:18:14 +0200 Message-ID: Thread-Topic: [AAA-WG]: draft-ietf-aaa-diameter preview (fwd) Thread-Index: AcLCK2olAa4rfwl6T/KZDaNfxMj8KQABmhoQ From: To: X-OriginalArrivalTime: 22 Jan 2003 16:18:15.0033 (UTC) FILETIME=[DDCF4690:01C2C231] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA29509 Hi all, I'll provide a list of changes & updates in the next day or two .. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 22 January, 2003 16:20 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: draft-ietf-aaa-diameter preview (fwd) > > > > > ---------- Forwarded message ---------- > Date: Wed, 22 Jan 2003 10:30:01 +0200 > From: john.loughney@nokia.com > To: aaa-editors@internaut.com > Cc: randy@psg.com, bwijnen@lucent.com > Subject: draft-ietf-aaa-diameter preview > > Hi all, > > I have updated the Diameter base spec, I want to a read of it > before submitting, but the current version can be found here: > > http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-17.txt > > The plan is to submit it shortly, so that Randy can put it on > the IESG conference call agenda tomorrow. > > thanks, > John > > From owner-aaa-wg@merit.edu Fri Jan 24 16:03:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02415 for ; Fri, 24 Jan 2003 16:03:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52CA091451; Fri, 24 Jan 2003 16:06:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24BE191453; Fri, 24 Jan 2003 16:06:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F030591451 for ; Fri, 24 Jan 2003 16:06:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id D33705DFC1; Fri, 24 Jan 2003 16:06:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3A8005DE4B for ; Fri, 24 Jan 2003 16:06:31 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0OJtk226931 for ; Fri, 24 Jan 2003 11:55:46 -0800 Date: Fri, 24 Jan 2003 11:55:46 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Issue 386: MIP-13 Security Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk -----Original Message----- From: Tony Johansson Sent: Sunday, January 19, 2003 5:13 PM To: aaa-editors@internaut.com; 'smb@research.att.com' Subject: RE: Issue 386: MIP-13 Security Issues Steve, All, Se comments embedded below. Thanks, /Tony >Issue 386: MIP-13 Security Issues >Submitter name: Steve Bellovin >Submitter email address: smb@research.att.com >Date first submitted: November 11, 2002 >Reference: >Document: MIP-13 >Comment type: T >Priority: S >Section: Various >Rationale/Explanation of issue: >1.6: What is a "preconfigured shared security association"? Do you >mean a preshared secret? A security association comprises far more >than just a key. [Tony]: In RFC3220 they use security association, which they mean a shared secret. So, what should I say preconfigured shared secret? >I have not evaluated the security of the scheme in this section, since >it depends on another draft, and possibly on the security of MobileIP >itself. Can we really even consider this draft until those are done? >1.10: What firewall rules? Are the agents supposed to tell their local >firewalls to open up some holes? [Tony]: Per discussion from the review meeting last week - how about the following text: .in 0 1.10 IP filter rule support .in 3 This application has support for pushing filter rules to either of the mobility agents to enable appropriate restrictions for the mobile node, such as limiting the mobile nodes access due to roaming agreements or network protection. The filter rules are set by the AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if destined for the home agent and/or in the AMA if destined for the foreign agent. The filer rules does only apply to the mobile node in the HAR and/or AMA message, thus the mobility agents will process the filter rules individually for each mobile node. If MIP-Filter-Rule AVPs are included in the HAR and the home agent does not have support to handle filter rules, the home agent MUST return a HAA with Result-Code AVP equal to DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED. If the MIP-Filter-Rule AVPs are included in the AMA and the foreign agent does not have support to handle filter rules, the foreign agent SHOULD log the event and MUST issue a Session-Termination-Request (STR) back to its local Diameter server. >5.2: 64 bits is not sufficient for a key. Why not just mandate 128, >instead of strongly recommending it? [Tony]: This was due to the Mobile IP AAA key distribution draft, which we are dependent on, however draft-draft-ietf-mobileip-aaa-key-10.txt has now changed to mandate 128 bit. So, 128 bit is now mandated. >5: I confess that it still isn't clear to me how the home and foreign >agents know authoritatively who each other are. Then again, that's >always been my main complaint about AAA. But here they're handing out >keys. [Tony]: Reading through the Diameter MIPv4 application draft again, I not sure what is missing to make it more understandable. I really need some help here. From owner-aaa-wg@merit.edu Fri Jan 24 18:13:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05118 for ; Fri, 24 Jan 2003 18:13:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF6509124F; Fri, 24 Jan 2003 18:14:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8764D91252; Fri, 24 Jan 2003 18:14:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E41A59124F for ; Fri, 24 Jan 2003 18:14:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA7DD5DE53; Fri, 24 Jan 2003 18:14:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4F58E5DDBD for ; Fri, 24 Jan 2003 18:14:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0OM46V02223 for ; Fri, 24 Jan 2003 14:04:06 -0800 Date: Fri, 24 Jan 2003 14:04:06 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Base Protocol approved as an IETF Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Yesterday, on the IESG conference call, the Diameter Base Protocol (Draft 17) was approved as an IETF Proposed Standard. Many thanks to everyone in the AAA WG who have worked on this over the years. To Pat Calhoun, who was present at the birth; to Erik Guttman, who helped raise it during its rebellious teenage years; to John Loughney who served as editor and foster parent; to Glen Zorn and Jari Arkko, the kindly uncles who contributed wise advice along the way. And to all the members of the AAA WG who read the specification, even when it was not as palatable as it is today -- and contributed an Issue, or the resolution of an Issue. To all of you -- you have my permission to have a glass of champagne tonite :) Bernard From owner-aaa-wg@merit.edu Fri Jan 24 18:32:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05389 for ; Fri, 24 Jan 2003 18:32:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F29BF91252; Fri, 24 Jan 2003 18:36:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C863391455; Fri, 24 Jan 2003 18:35:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A33EF91252 for ; Fri, 24 Jan 2003 18:35:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1A6E5DEAC; Fri, 24 Jan 2003 18:35:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5688E5DE1B for ; Fri, 24 Jan 2003 18:35:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0OMPCs03320 for ; Fri, 24 Jan 2003 14:25:12 -0800 Date: Fri, 24 Jan 2003 14:25:12 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 398: Fixes for the RFC Editor Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk A Diameter Base issue, for old times sake :) Issue 398: Fixes for the RFC Editor Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 23, 2002 Document: BASE-17 Comment type: Editorial Priority: 2 Section: 1 Change: "Initially, it is expected that Diameter will be deployed within new network devices, as well as within gateways enabling communication between legacy RADIUS devices and s." To: "Initially, it is expected that Diameter will be deployed within new network devices, as well as within gateways enabling communication between legacy RADIUS devices and Diameter agents." From owner-aaa-wg@merit.edu Tue Jan 28 01:59:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07821 for ; Tue, 28 Jan 2003 01:59:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F402E912EE; Tue, 28 Jan 2003 02:03:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16FFE912EC; Tue, 28 Jan 2003 02:02:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B794A912ED for ; Tue, 28 Jan 2003 02:02:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 862E95E003; Tue, 28 Jan 2003 02:02:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0EAE45DD8E for ; Tue, 28 Jan 2003 02:02:15 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0S5pBp08399 for ; Mon, 27 Jan 2003 21:51:11 -0800 Date: Mon, 27 Jan 2003 21:51:11 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Document Action: Diameter Command Codes for 3GPP Release 5 to Informational Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Document Action: Diameter Command Codes for 3GPP Release 5 to Informational -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: Document Action: Diameter Command Codes for 3GPP Release 5 to Informational From: The IESG Date: Mon, 27 Jan 2003 20:56:19 -0500 Cc: RFC Editor , Internet Architecture Board Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- The IESG has approved the Internet-Draft 'Diameter Command Codes for 3GPP Release 5' as an Informational RFC. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Randy Bush. From owner-aaa-wg@merit.edu Tue Jan 28 02:01:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09430 for ; Tue, 28 Jan 2003 02:01:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59B5B912EC; Tue, 28 Jan 2003 02:04:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2300C912ED; Tue, 28 Jan 2003 02:04:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1786D912EC for ; Tue, 28 Jan 2003 02:04:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC82E5E003; Tue, 28 Jan 2003 02:04:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6B3A05DD8E for ; Tue, 28 Jan 2003 02:04:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0S5rIA08510 for ; Mon, 27 Jan 2003 21:53:18 -0800 Date: Mon, 27 Jan 2003 21:53:18 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Protocol Action: Diameter Base Protocol to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Protocol Action: Diameter Base Protocol to Proposed Standard -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: Protocol Action: Diameter Base Protocol to Proposed Standard From: The IESG Date: Mon, 27 Jan 2003 20:55:47 -0500 Cc: RFC Editor , Internet Architecture Board , aaa-wg@merit.edu Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- The IESG has approved the Internet-Draft 'Diameter Base Protocol' as a Proposed Standard. This document is the product of the Authentication, Authorization and Accounting Working Group. The IESG contact persons are Randy Bush and Bert Wijnen. Technical Summary This document is the base for the proposed new IETF AAA protocol suite. The base protocol is intended to provide an AAA framework for applications such as network access and IP mobility. Diameter is also intended to work in both local AAA and in roaming situations. This draft specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application MUST be supported by all Diameter implementations. Working Group Summary There was no technical dissent to this document in the aaa working group or during IETF last call. Protocol Quality This document was reviewed for the IESG by Randy Bush, and many others. From owner-aaa-wg@merit.edu Tue Jan 28 14:22:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04380 for ; Tue, 28 Jan 2003 14:22:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D824A91331; Tue, 28 Jan 2003 14:26:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E66991332; Tue, 28 Jan 2003 14:26:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7682A91331 for ; Tue, 28 Jan 2003 14:26:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6310E5DFA1; Tue, 28 Jan 2003 14:26:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id A87B05DF54 for ; Tue, 28 Jan 2003 14:26:12 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SJSYg19114 for ; Tue, 28 Jan 2003 21:28:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 28 Jan 2003 21:26:06 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 21:26:06 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 21:26:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Diameter Base Update details Date: Tue, 28 Jan 2003 21:26:05 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 398: Fixes for the RFC Editor Thread-Index: AcLEAWYJxWyJHvg0SPqulYOOm/I7XADAYhUw From: To: X-OriginalArrivalTime: 28 Jan 2003 19:26:05.0920 (UTC) FILETIME=[1A42A600:01C2C703] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA04380 Hi all, I've tried to summarize the major changes in the Diameter base spec from 16 to 17. thanks, John Diameter 17 Updates 1) "Accounting-RADIUS-Session-Id" (44) changed to "Accounting-Session-Id" 2) Section 1.2.4, 3rd paragraph, Page 14 changed to: "Every Diameter implementation MUST support accounting. Basic accounting support is sufficient to handle any application that uses the ACR/ACA commands defined in this document, as long as no new mandatory AVPs are added. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application." 3) Sections 2.4 & 11.3, 2nd paragraph changed to: Diameter Base Accounting 0 NASREQ 1 [NASREQ] Mobile-IP 4 [DIAMMIP] Relay 0xffffffff 4) General cleanup on "SHOULD be placed as close to the Diameter header as possible." 5) Added reference to 2194 6) added to 4.6 E2E-Sequence AVP 300 6.15 Grouped | M | P | | V | Y | 7) User defined. 8) End-to-end security definition improved 9) IPAddress changed to Address & format now includes a 16 bit address type, to discriminate IPv4, IPv6, etc. addresses 10) Error-Message changed to UTF8String 11) Host-IP-Address AVP (AVP Code 257) type changed to Address (from IPAddress) 12) Text for section "11.1.1 AVP Codes" updated. 13) Fixed allocation range for Application IDs, Section 11.3 IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0x01000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. The following values are allocated. From owner-aaa-wg@merit.edu Tue Jan 28 19:22:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12314 for ; Tue, 28 Jan 2003 19:22:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE1989122A; Tue, 28 Jan 2003 19:24:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01DB291359; Tue, 28 Jan 2003 19:24:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CD3191358 for ; Tue, 28 Jan 2003 19:24:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A7325DFA4; Tue, 28 Jan 2003 19:24:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BBFDB5DF9F for ; Tue, 28 Jan 2003 19:24:12 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0SND5X02059 for ; Tue, 28 Jan 2003 15:13:05 -0800 Date: Tue, 28 Jan 2003 15:13:05 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Fwd: Clarification on RFC-2865 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=------------1B64FBA3D66D776C041EB6B9 Content-ID: Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------1B64FBA3D66D776C041EB6B9 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Tue, 28 Jan 2003 12:20:29 -0800 From: Philip A. Prindeville To: Bernard Aboba Subject: Fwd: Clarification on RFC-2865 It seems the old Radius WG is disbanded. I was hoping someone could answer a couple of basic questions that the specs left ambiguous. Thanks, -Philip --------------1B64FBA3D66D776C041EB6B9 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Content-Disposition: INLINE Message-ID: <3E307BD0.83B6C7B8@cisco.com> Date: Thu, 23 Jan 2003 15:33:36 -0800 From: "Philip A. Prindeville" X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,fr-FR MIME-Version: 1.0 To: cdr@telemancy.com, acr@merit.edu, wsimpson@greendragon.com, steve@livingston.com Subject: Clarification on RFC-2865 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have a couple of questions regarding the exact semantics of some Radius attributes. I was hoping you could set me straight. In the case of Ascend attribute 104 (outside of the scope of the document, I know): Can this attribute have overlapping instances when it occurs more than once? And does it imply that the routes must be tested in the order they are given by the server? For instance, in the (dubious) case of getting back: Ascend-Private-Route="170.0.0.0/8 10.10.10.1" Ascend-Private-Route="170.1.0.0/16 10.10.10.1" Is this the same as: Ascend-Private-Route="170.1.0.0/16 10.10.10.1" Ascend-Private-Route="170.1.0.0/8 10.10.10.1" (ordering by specificity) or just: Ascend-Private-Route="170.0.0.0/8 10.10.10.1" (since the less specific route would match both cases?) There are implementation and performance implications of doing it either way. The more open interpretation requires searching linearly for the first match (since this would allow multiple matches). The more restrictive interpretation allows for an efficient tree-based search, since the first match is also the only match. And the next question is about the Framed-IP-Address attribute (#8): If the NAS receives this from the Radius server with the value 255.255.255.255 (remote host should select address), does this mean that the NAS should balk if the remote host doesn't furnish a valid address? Or should it fall back on a local address pool, and pick one from there? This latter behaviour is not implied by the standard, and introduces an ambiguity in the protocol that relies entirely on the local state of the NAS (i.e. whether it has a local address pool configured or not). I think that the correct interpretation is to fail the negotiation, but this is obviously a more restrictive interpretation. What's your collective opinion? Thanks, -Philip --------------1B64FBA3D66D776C041EB6B9-- From owner-aaa-wg@merit.edu Tue Jan 28 21:07:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14062 for ; Tue, 28 Jan 2003 21:07:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7ED7391362; Tue, 28 Jan 2003 21:07:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DCC79122D; Tue, 28 Jan 2003 21:07:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 858CB91367 for ; Tue, 28 Jan 2003 21:06:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6EDB75DF58; Tue, 28 Jan 2003 21:06:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C4A295DF36 for ; Tue, 28 Jan 2003 21:06:51 -0500 (EST) Received: from localhost (httpd@localhost) by internaut.com (8.10.2/8.10.2) with SMTP id h0T0teL07768; Tue, 28 Jan 2003 16:55:40 -0800 Message-Id: <200301290055.h0T0teL07768@internaut.com> X-Authentication-Warning: internaut.com: httpd owned process doing -bs To: "Philip A. Prindeville" Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Clarification on RFC 2865 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Cobalt Webmail Date: Tue, 28 Jan 2003 16:55:40 -0800 From: Bernard Aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk Since the attributes you cite can also be used with Diameter NASREQ, I'm posting your questions to the AAA WG list, so that we can make sure that NASREQ includes the clarifications. ================================================== Message-ID: <3E307BD0.83B6C7B8@cisco.com> Date: Thu, 23 Jan 2003 15:33:36 -0800 From: "Philip A. Prindeville" X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,fr-FR MIME-Version: 1.0 To: cdr@telemancy.com, acr@merit.edu, wsimpson@greendragon.com, steve@livingston.com Subject: Clarification on RFC-2865 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have a couple of questions regarding the exact semantics of some Radius attributes. I was hoping you could set me straight. In the case of Ascend attribute 104 (outside of the scope of the document, I know): Can this attribute have overlapping instances when it occurs more than once? And does it imply that the routes must be tested in the order they are given by the server? For instance, in the (dubious) case of getting back: Ascend-Private-Route="170.0.0.0/8 10.10.10.1" Ascend-Private-Route="170.1.0.0/16 10.10.10.1" Is this the same as: Ascend-Private-Route="170.1.0.0/16 10.10.10.1" Ascend-Private-Route="170.1.0.0/8 10.10.10.1" (ordering by specificity) or just: Ascend-Private-Route="170.0.0.0/8 10.10.10.1" (since the less specific route would match both cases?) There are implementation and performance implications of doing it either way. The more open interpretation requires searching linearly for the first match (since this would allow multiple matches). The more restrictive interpretation allows for an efficient tree-based search, since the first match is also the only match. And the next question is about the Framed-IP-Address attribute (#8): If the NAS receives this from the Radius server with the value 255.255.255.255 (remote host should select address), does this mean that the NAS should balk if the remote host doesn't furnish a valid address? Or should it fall back on a local address pool, and pick one from there? [BA] I think this may depend on the media. Within PPP, the address would be negotiated within IPCP, and presumably if the NAS did not like the address suggested by the peer, it could assign its own. However, for other media such as IEEE 802, the NAS is not directly involved in address assignment (e.g. most switches/APs just forward DHCP packets) so it may be harder to give guidance (unless the switch/AP can also act as a DHCP server). --------------------------------------------- This latter behaviour is not implied by the standard, and introduces an ambiguity in the protocol that relies entirely on the local state of the NAS (i.e. whether it has a local address pool configured or not). I think that the correct interpretation is to fail the negotiation, but this is obviously a more restrictive interpretation. What's your collective opinion? Thanks, -Philip ---------- Original message ---------- Date: Tue, 28 Jan 2003 12:20:29 -0800 From: Philip A. Prindeville Reply-To: Philip A. Prindeville To: Bernard Aboba Subject: Fwd: Clarification on RFC-2865 It seems the old Radius WG is disbanded. I was hoping someone could answer a couple of basic questions that the specs left ambiguous. Thanks, -Philip From owner-aaa-wg@merit.edu Tue Jan 28 21:54:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14831 for ; Tue, 28 Jan 2003 21:54:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CBCD79122D; Tue, 28 Jan 2003 21:58:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95A2691230; Tue, 28 Jan 2003 21:58:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 791949122D for ; Tue, 28 Jan 2003 21:58:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6117F5DF5D; Tue, 28 Jan 2003 21:58:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id CC2585DE2D for ; Tue, 28 Jan 2003 21:58:11 -0500 (EST) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0T2wAV11589; Tue, 28 Jan 2003 21:58:10 -0500 (EST) Received: from new-wopr.eng.ascend.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id VAA24023 for ; Tue, 28 Jan 2003 21:58:08 -0500 (EST) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.10.2+Sun/8.10.2) with ESMTP id h0T2w8Y28941; Tue, 28 Jan 2003 18:58:08 -0800 (PST) Received: from igoyret-t23 (dhcp-135-140-27-159.eng.ascend.com [135.140.27.159]) by grigri.eng.ascend.com (8.8.8+Sun/8.8.8) with SMTP id SAA24068; Tue, 28 Jan 2003 18:58:08 -0800 (PST) Message-Id: <200301290258.SAA24068@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 28 Jan 2003 18:57:50 -0800 To: Bernard Aboba From: Ignacio Goyret Subject: Re: [AAA-WG]: Re: Clarification on RFC 2865 Cc: "Philip A. Prindeville" , aaa-wg@merit.edu In-Reply-To: <200301290055.h0T0teL07768@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk >Date: Thu, 23 Jan 2003 15:33:36 -0800 >From: "Philip A. Prindeville" >MIME-Version: 1.0 >To: cdr@telemancy.com, acr@merit.edu, wsimpson@greendragon.com, > steve@livingston.com >Subject: Clarification on RFC-2865 > >I have a couple of questions regarding the exact >semantics of some Radius attributes. I was hoping you >could set me straight. > >In the case of Ascend attribute 104 (outside of the scope of the document, I know): > >Can this attribute have overlapping instances when it >occurs more than once? FWIW, we (Ascend) always allowed overlapping instances. >And does it imply that the >routes must be tested in the order they are given by >the server? No. From owner-aaa-wg@merit.edu Fri Jan 31 13:07:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14167 for ; Fri, 31 Jan 2003 13:07:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 53FC891283; Fri, 31 Jan 2003 13:10:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2396691284; Fri, 31 Jan 2003 13:10:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6348991283 for ; Fri, 31 Jan 2003 13:10:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53A445DDE8; Fri, 31 Jan 2003 13:10:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h002.c000.snv.cp.net [209.228.32.66]) by segue.merit.edu (Postfix) with SMTP id 031185DDB2 for ; Fri, 31 Jan 2003 13:10:51 -0500 (EST) Received: (cpmta 421 invoked from network); 31 Jan 2003 10:10:49 -0800 Received: from 24.147.218.40 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 31 Jan 2003 10:10:49 -0800 X-Sent: 31 Jan 2003 18:10:49 GMT Message-Id: <5.2.0.9.2.20030131094717.042d71b0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Jan 2003 13:14:25 -0500 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Issue 395: NASREQ-10 comments Cc: Bernard Aboba Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Changes relative to comments, as below On 12/28/2002 02:53 PM -0600, Kuntal Chowdhury wrote: >Hello, >Here is a list of comments on nasreq-10 draft. The draft seems to be quite >stable. Did not find any major issue. > >Regards, >Kuntal > >------------------------------------------------------------------------ >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: E >Priority: 1 >Section: 4.1.3 >Rationale/Explanation of issue: >...This AVP SHOULD be present if the NAS uses the same NAS-Port > number ranges for different services types concurrently. >Proposal: > >...This AVP SHOULD be present if the NAS uses the same NAS-Port > number ranges for different service types concurrently. >> accepted - change plural service >---------------------------------------------------------------- > >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: T >Priority: 1 >Section: 4.2.6 >Rationale/Explanation of issue: > > CHAP with MD5 5 > The CHAP response is computed using the procedure described in > [PPPCHAP]. The CHAP-Response AVP MUST be present in the CHAP- > Auth AVP. > >Comment: We should not talk about CHAP-Response AVP in the CHAP-Algorithm >AVP section. Also according to the ABNF grammar, the CHAP-Response AVP is >not mandatory in CHAP-Auth AVP. > >Proposal: Delete the paragraph below CHAP with MD5 5. >> declined - The CHAP-Auth grouping was designed to allow a number of different CHAP algorithms, each with seperate AVP constraints. Because only one has been defined, it looks a little odd. The CHAP-Response AVP is grammarically optional, but required by the specification of CHAP with MD5. Other algorithms may require other AVPs and not CHAP-Response. >----------------------------------------------------------------- >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: T >Priority: 2 >Section: 4.4 >Rationale/Explanation of issue: >Tunneling AVP is of type Grouped but MAY NOT be encrypted. Whereas CHAP-Auth >AVP MAY be encrypted, but it is of type Grouped as well. In the entire spec >Tunneling AVP is the only one that has "N" in MAY Encr column. Is this an >error >or is there a reason for it? Since almost all of the AVPs have MAY Encr = Y >this column can be replaced by a global declaration ( e.g. may encrypt all >AVPs). >> This confuses me a little too. I'll have to look into it further and consult "those that understand our security representation". >------------------------------------------------------------------- > >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: T >Priority: 1 >Section: 5.8 >Rationale/Explanation of issue: > > Acct-Multi- Accounting- Acct- > Session-Id Session-Id Record-Type Link-Count > -------------------------------------------------------- > "...10" "...10" START_RECORD 1 > "...10" "...11" START_RECORD 2 > "...10" "...11" STOP_RECORD 2 > "...10" "...12" START_RECORD 3 > "...10" "...13" START_RECORD 4 > "...10" "...12" STOP_RECORD 4 > "...10" "...13" STOP_RECORD 4 > "...10" "...10" STOP_RECORD 4 > >At the fourth step, the Acct-Link-Count should be 2, because at the third >step the link with session-Id ...11 was closed, thus leaving only session-Id >...10 open. >> This example is lifted directly from RFC 2866, Section 5.12. The description is slightly different, but the intended semantics are the same. The value indicates the "total" number of links _seen_ over time on this session by the time the record is sent. Active or not. It never decreases. RFC 2866 said: contains the number of links seen so far in this Multilink Session. I edit this text to clarify further: indicates the total number of links that have been active (current or closed) in a given multilink session, at the time the accounting record is generated. >---------------------------------------------------------------- > >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: T >Priority: 1 >Section: 6.1.1 >Rationale/Explanation of issue: > > - If a Proxy-Info AVP is present, extract the encoded information, > otherwise retrieve the information from the local state table. > > - If a Proxy-Info AVP was present in the request, the same AVP > MUST be added to the response. > >The Proxy-Info AVP is not supported in RADIUS. Should it be Proxy-State AVP >instead? >> You're right, in the first bullet, it should read: if a Proxy-State attribute is present, ... This is following our recommendation in the prior section to encode Proxy-Info information in a Proxy-State attribute. The second bullet is correct as is. It is talking about this situation, where Proxy-Info was in the Diameter Request that caused this gateway's RADIUS translation. >----------------------------------------------------------------- > >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: E >Priority: 1 >Section: 6.2 >Rationale/Explanation of issue: > > The AVPs defined in this section SHOULD only used for backwards > compatibility when a Diameter/RADIUS translation function is invoked, > and are not typically originated by Diameter systems. > >Proposal: > The AVPs defined in this section SHOULD only be used for backward > compatibility when a Diameter/RADIUS translation function is invoked, > and are not typically originated by Diameter systems during normal > operation. >> accepted >---------------------------------------------------------------- > >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: E/T >Priority: 1 >Section: 7.2.1 and 7.2.2 >Rationale/Explanation of issue: >The AVPs that are MUST not be present in a command Request/Answer are still >shown in the table. > >Proposal: >Section 7.2.1 >State AVP MUST not be present in both ACR and ACA. There is no need to show >it in the table. Delete this entry. >> Okay. This appears to be a carryover from RFC2866 sect 5.13 The State attribute is explictly called out to be not-allowed. >Section 7.2.2: >Same as above: delete Accounting-Input-Packets, Accounting-Output-Packets, >NAS-Filter-Rule, State entries from the AVP table for these types of >accounting messages. >> I guess so. Their presence serves as a comparator from the other accounting table. I might take a crack at combining these two tables. >----------------------------------------------------------------- > >Description of issue >Submitter name: Kuntal Chowdhury >Submitter email address: chowdury@nortelnetworks.com >Date first submitted: 12/28/02 >Reference: >Document: nasreq >Comment type: E >Priority: 1 >Section: 10 >Rationale/Explanation of issue: > >Update reference for CDMA2000 with the latest release of the standard. > >[CDMA2000] 3GPP2 "P.S0001-A v3.0", Wireless IP Network Standard, July > 2001. > >http://www.3gpp2.com/Public_html/specs/P.S0001-A_v3.0.pdf > >Proposal: > >[CDMA2000] 3GPP2 "P.S0001-B", Wireless IP Network Standard, October > 2002. > >http://www.3gpp2.com/Public_html/specs/P.S0001-B_v1.0.pdf > >> Thanks, will do. Dave.