From owner-aaa-bof@merit.edu Wed Mar 1 10:12:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16135 for ; Wed, 1 Mar 2000 10:12:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B2F85DD8C; Wed, 1 Mar 2000 10:12:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 233965DD95; Wed, 1 Mar 2000 10:12:02 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id D75235DD8C for ; Wed, 1 Mar 2000 10:11:52 -0500 (EST) Received: from pcrperlman (IDENT:root@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id HAA06291; Wed, 1 Mar 2000 07:11:46 -0800 (PST) (envelope-from perl@lucent.com) Message-Id: <4.2.2.20000301100534.00a991d0@mail.yikes.com> X-Sender: rdp@mail.yikes.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 01 Mar 2000 10:09:29 +0800 To: =?iso-8859-1?Q?=22Tom_K=2E_Weckstr=F6m=22?= , "pcalhoun@eng.sun.com" From: Richard Perlman Subject: Re: Revised Network Access Requirements doc (Fwd) Cc: aaa-wg@merit.edu In-Reply-To: <38BA1C67.61635B51@cc.hut.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA16135 Tom: I agree, such a "hold on a sec" features may be complicated to implement. However, it is a real requirement for operators very wide area (i.e. global) networks with complex roaming and exchange relationships. With today's RADIUS implementations they must set a single timeout on the NAS -- and they must choose the longest possible time. This creates a less than optimal retry scenario for local AAA servers. Richard At 08:57 AM 02/28/2000 +0200, Tom K. Weckström wrote: >I prefer the latter as well. >As Richard noted, having a time limit in protocol requirements may not >be a good idea. > >As a comment to Richard's idea of negotiating whether the required speed >can be provided: I'd say that let's keep this simple. Having such >negotiations would further complicate the state machine, the number of >messages etc. The future AAA protocol will be complicated enough even >without such elaborated negotiations. The simpler - the faster - the >better. From owner-aaa-bof@merit.edu Wed Mar 1 10:33:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16461 for ; Wed, 1 Mar 2000 10:33:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7CD95DDA4; Wed, 1 Mar 2000 10:32:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BBD115DDA8; Wed, 1 Mar 2000 10:32:47 -0500 (EST) Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by segue.merit.edu (Postfix) with ESMTP id 2A5845DDA4 for ; Wed, 1 Mar 2000 10:32:46 -0500 (EST) Received: from akaatti.hut.fi (tweckstr@akaatti.hut.fi [130.233.249.61]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id RAA28639; Wed, 1 Mar 2000 17:32:39 +0200 (EET) Date: Wed, 1 Mar 2000 17:32:36 +0200 (EET) From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: Richard Perlman Cc: "pcalhoun@eng.sun.com" , aaa-wg@merit.edu Subject: Re: Revised Network Access Requirements doc (Fwd) In-Reply-To: <4.2.2.20000301100534.00a991d0@mail.yikes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-aaa-bof@merit.edu Precedence: bulk Richard, I might give in and agree... :) On the core network side (between NASes and AAA Servers) this kind of a negotiation might be a good thing. I was initially against a solution in which the end user, e.g. a Mobile Node, would have to go through painful message exchanges for different kind of parameters to set up the connection. >From a Mobile IP end user point of view, the agent advertisements should contain enough information for the mobile to request a connection with specific parameters, and the next message for the Mobile would be a registration reply. BTW, single (or at least minimial number of) internet traversal is a requirement for a MIP + AAA registration, isn't it? Regards, Tom On Wed, 1 Mar 2000, Richard Perlman wrote: perl >Tom: perl > perl >I agree, such a "hold on a sec" features may be complicated to perl >implement. However, it is a real requirement for operators very wide area perl >(i.e. global) networks with complex roaming and exchange perl >relationships. With today's RADIUS implementations they must set a single perl >timeout on the NAS -- and they must choose the longest possible time. This perl >creates a less than optimal retry scenario for local AAA servers. perl > perl >Richard perl > perl >At 08:57 AM 02/28/2000 +0200, Tom K. Weckström wrote: perl >>I prefer the latter as well. perl >>As Richard noted, having a time limit in protocol requirements may not perl >>be a good idea. perl >> perl >>As a comment to Richard's idea of negotiating whether the required speed perl >>can be provided: I'd say that let's keep this simple. Having such perl >>negotiations would further complicate the state machine, the number of perl >>messages etc. The future AAA protocol will be complicated enough even perl >>without such elaborated negotiations. The simpler - the faster - the perl >>better. perl > -- Tom Weckström tweckstr@cc.hut.fi Helsinki University of Technology Department of Computer Science From owner-aaa-bof@merit.edu Wed Mar 1 12:08:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA18132 for ; Wed, 1 Mar 2000 12:08:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3232F5DD9A; Wed, 1 Mar 2000 12:07:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1FDD45DDC0; Wed, 1 Mar 2000 12:07:43 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-38.ricochet.net [206.253.202.38]) by segue.merit.edu (Postfix) with ESMTP id 595185DD9A for ; Wed, 1 Mar 2000 12:07:39 -0500 (EST) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id IAA59268 for ; Wed, 1 Mar 2000 08:58:01 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: AAA WG Last Call on draft-ietf-aaa-accounting-attributes-01.txt Date: Wed, 1 Mar 2000 09:07:37 -0800 Message-ID: <013f01bf83a0$a5a08630$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk This is the AAA Working Group last call on draft-ietf-aaa-accounting-attributes-01.txt before sending it on to IETF Last Call. This draft is recommended for Informational status. If you have comments on it, please send them to the authors or to the aaa-wg@merit.edu mailing list BEFORE March 16. http://www.ietf.org/internet-drafts/draft-ietf-aaa-accounting-attributes-01. txt From owner-aaa-bof@merit.edu Wed Mar 1 12:10:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA18172 for ; Wed, 1 Mar 2000 12:10:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5850F5DDC0; Wed, 1 Mar 2000 12:09:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 48A1B5DDC4; Wed, 1 Mar 2000 12:09:46 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-38.ricochet.net [206.253.202.38]) by segue.merit.edu (Postfix) with ESMTP id 3D5FA5DDC0 for ; Wed, 1 Mar 2000 12:09:39 -0500 (EST) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA59278 for ; Wed, 1 Mar 2000 09:00:01 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: AAA WG Last Call on draft-ietf-aaa-na-reqts-02.txt Date: Wed, 1 Mar 2000 09:09:37 -0800 Message-ID: <014001bf83a0$ed5415a0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk This is the AAA Working Group last call on draft-ietf-aaa-na-reqts-02.txt before sending it on to IETF Last Call. This draft is recommended for Informational status. If you have comments on it, please send them to the authors or to the aaa-wg@merit.edu mailing list BEFORE March 16. http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-02.txt From owner-aaa-bof@merit.edu Wed Mar 1 23:14:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA11680 for ; Wed, 1 Mar 2000 23:14:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B5E05DDF0; Wed, 1 Mar 2000 23:14:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1BA915DE41; Wed, 1 Mar 2000 23:14:06 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id 60FA85DDF0 for ; Wed, 1 Mar 2000 23:13:58 -0500 (EST) Received: from pcrperlman (IDENT:root@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id UAA15094; Wed, 1 Mar 2000 20:13:50 -0800 (PST) (envelope-from perl@lucent.com) Message-Id: <4.2.2.20000301230759.00a46f00@mail.yikes.com> X-Sender: rdp@mail.yikes.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 01 Mar 2000 23:09:40 +0800 To: Tom =?iso-8859-1?Q?Weckstr=F6m?= From: Richard Perlman Subject: Re: Revised Network Access Requirements doc (Fwd) Cc: "pcalhoun@eng.sun.com" , aaa-wg@merit.edu In-Reply-To: References: <4.2.2.20000301100534.00a991d0@mail.yikes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id XAA11680 Tom: I think the limitation that the message exchange for delay time could be only between the initial AAA client (nominally a NAS) and the first AAA server. Other comments anyone? Richard At 05:32 PM 03/01/2000 +0200, Tom Weckström wrote: >I might give in and agree... :) On the core network side (between NASes >and AAA Servers) this kind of a negotiation might be a good thing. I was >initially against a solution in which the end user, e.g. a Mobile Node, >would have to go through painful message exchanges for different kind of >parameters to set up the connection. > >From a Mobile IP end user point of view, the agent advertisements should >contain enough information for the mobile to request a connection with >specific parameters, and the next message for the Mobile would be a >registration reply. >BTW, single (or at least minimial number of) internet traversal is a >requirement for a MIP + AAA registration, isn't it? > >Regards, > Tom > >On Wed, 1 Mar 2000, Richard Perlman wrote: > >perl >Tom: >perl > >perl >I agree, such a "hold on a sec" features may be complicated to >perl >implement. However, it is a real requirement for operators very >wide area >perl >(i.e. global) networks with complex roaming and exchange >perl >relationships. With today's RADIUS implementations they must set a >single >perl >timeout on the NAS -- and they must choose the longest possible >time. This >perl >creates a less than optimal retry scenario for local AAA servers. >perl > >perl >Richard >perl > >perl >At 08:57 AM 02/28/2000 +0200, Tom K. Weckström wrote: >perl >>I prefer the latter as well. >perl >>As Richard noted, having a time limit in protocol requirements may not >perl >>be a good idea. >perl >> >perl >>As a comment to Richard's idea of negotiating whether the required >speed >perl >>can be provided: I'd say that let's keep this simple. Having such >perl >>negotiations would further complicate the state machine, the number of >perl >>messages etc. The future AAA protocol will be complicated enough even >perl >>without such elaborated negotiations. The simpler - the faster - the >perl >>better. >perl > > >-- > Tom Weckström tweckstr@cc.hut.fi > Helsinki University of Technology > Department of Computer Science From owner-aaa-bof@merit.edu Thu Mar 2 09:05:22 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19556 for ; Thu, 2 Mar 2000 09:05:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1FF25DDCD; Thu, 2 Mar 2000 09:05:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B00465DDD5; Thu, 2 Mar 2000 09:05:02 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 510395DDCD for ; Thu, 2 Mar 2000 09:05:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09401; Thu, 2 Mar 2000 06:04:53 -0800 (PST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.51.34]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA27853; Thu, 2 Mar 2000 06:04:52 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27556; Thu, 2 Mar 2000 06:04:51 -0800 Date: Thu, 2 Mar 2000 06:04:51 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Revised Network Access Requirements doc (Fwd) To: =?iso-8859-1?Q?Tom_Weckstr=F6m?= Cc: Richard Perlman , "pcalhoun@eng.sun.com" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.merit.edu id JAA19556 The 'hold on a sec' message (HOAS) was discussed some time back in the RADIUS world. The reason why it was even desired in that space was that the protocol provides no reliability whatsoever. A request is acknowledged when a response is received, and if the request must traverse a set of proxies, it is difficult to actually know whether the request was ever delivered. If the end server had a slow database lookup, it would cause the NAS to retransmit the request. In the AAA world, if each proxy in the network is responsible for ensuring that the message made it to the next hop, via message acknowledgement, then that node is responsible for re-routing the packet to an alternative hop if at all possible. So, the HOAS would only make it to the next hop in the chain, not all the way back to the NAS, IMHO, and the ONLY place that the HOAS message would be generated, is at the home server, where a possibly slow database lookup will occur. Note that the AAA protocol also assumes that there is flow control, which will also eliminate one of the reasons why the HOAS was desired in RADIUS, which could get 1000's of messages and wouldn't be able to service them in a timely manner. So, the question is whether this feature is really needed. I'm not convinced (but can be, given the proper argument). PatC > > > Richard, > > I might give in and agree... :) On the core network side (between NASes > and AAA Servers) this kind of a negotiation might be a good thing. I was > initially against a solution in which the end user, e.g. a Mobile Node, > would have to go through painful message exchanges for different kind of > parameters to set up the connection. > From a Mobile IP end user point of view, the agent advertisements should > contain enough information for the mobile to request a connection with > specific parameters, and the next message for the Mobile would be a > registration reply. > BTW, single (or at least minimial number of) internet traversal is a > requirement for a MIP + AAA registration, isn't it? > > Regards, > Tom > > On Wed, 1 Mar 2000, Richard Perlman wrote: > > perl >Tom: > perl > > perl >I agree, such a "hold on a sec" features may be complicated to > perl >implement. However, it is a real requirement for operators very wide > area perl >(i.e. global) networks with complex roaming and exchange > perl >relationships. With today's RADIUS implementations they must set a > single perl >timeout on the NAS -- and they must choose the longest > possible time. This perl >creates a less than optimal retry scenario for > local AAA servers. perl > > perl >Richard > perl > > perl >At 08:57 AM 02/28/2000 +0200, Tom K. Weckström wrote: > perl >>I prefer the latter as well. > perl >>As Richard noted, having a time limit in protocol requirements may not > perl >>be a good idea. perl >> > perl >>As a comment to Richard's idea of negotiating whether the required > speed perl >>can be provided: I'd say that let's keep this simple. Having > such perl >>negotiations would further complicate the state machine, the > number of perl >>messages etc. The future AAA protocol will be complicated > enough even perl >>without such elaborated negotiations. The simpler - the > faster - the perl >>better. > perl > > > -- > Tom Weckström tweckstr@cc.hut.fi > Helsinki University of Technology > Department of Computer Science > From owner-aaa-bof@merit.edu Thu Mar 2 09:20:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19764 for ; Thu, 2 Mar 2000 09:20:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3969A5DDD6; Thu, 2 Mar 2000 09:16:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0CC045DDCE; Thu, 2 Mar 2000 09:16:34 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id 644EA5DDD6 for ; Thu, 2 Mar 2000 09:16:30 -0500 (EST) Received: from pcrperlman (IDENT:root@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id GAA19030; Thu, 2 Mar 2000 06:16:19 -0800 (PST) (envelope-from perl@lucent.com) Message-Id: <4.2.2.20000302090907.00a9d240@mail.yikes.com> X-Sender: rdp@mail.yikes.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 02 Mar 2000 09:15:20 +0800 To: "pcalhoun@eng.sun.com" , Tom =?iso-8859-1?Q?Weckstr=F6m?= From: Richard Perlman Subject: Re: Revised Network Access Requirements doc (Fwd) Cc: "pcalhoun@eng.sun.com" , aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat: The main need I am aware of is determining the time the client (NAS) will wait for a reply. The HOAS message would OPTIONALLY be sent to the NAS from the first AAA server to the client. Presumably the first AAA server could make some determination that the request would require some amount of extra time (the definition of extra is an implementation issue). To put it another way, this is a way for the initial AAA server to send a timeout override message to the client. Richard At 06:04 AM 03/02/2000 -0800, pcalhoun@eng.sun.com wrote: >The 'hold on a sec' message (HOAS) was discussed some time back in the RADIUS >world. The reason why it was even desired in that space was that the protocol >provides no reliability whatsoever. A request is acknowledged when a response >is received, and if the request must traverse a set of proxies, it is >difficult to actually know whether the request was ever delivered. If the end >server had a slow database lookup, it would cause the NAS to retransmit the >request. From owner-aaa-bof@merit.edu Thu Mar 2 10:11:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20469 for ; Thu, 2 Mar 2000 10:11:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFF995DDD7; Thu, 2 Mar 2000 10:11:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A3FAA5DDDD; Thu, 2 Mar 2000 10:11:20 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 441AE5DDD7 for ; Thu, 2 Mar 2000 10:11:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03392; Thu, 2 Mar 2000 07:11:14 -0800 (PST) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.91.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA08794; Thu, 2 Mar 2000 07:11:12 -0800 (PST) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13250; Thu, 2 Mar 2000 07:11:10 -0800 Date: Thu, 2 Mar 2000 07:11:10 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Revised Network Access Requirements doc (Fwd) To: Richard Perlman Cc: "pcalhoun@eng.sun.com" , =?iso-8859-1?Q?Tom_Weckstr=F6m?= , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <4.2.2.20000302090907.00a9d240@mail.yikes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat: > > The main need I am aware of is determining the time the client (NAS) will > wait for a reply. The HOAS message would OPTIONALLY be sent to the NAS > from the first AAA server to the client. Presumably the first AAA server > could make some determination that the request would require some amount > of extra time (the definition of extra is an implementation issue). > > To put it another way, this is a way for the initial AAA server to send a > timeout override message to the client. But in a complex and convoluted proxy chain arrangement, how would the first hop even know how long to tell the client to wait? I think in the RADIUS world, this was ONE way to try to slow down the retramissions from the NAS, but I'm not convinced that the AAA protocol would suffer from the same flaws that would require that include HOAS as well. PatC > > Richard > > At 06:04 AM 03/02/2000 -0800, pcalhoun@eng.sun.com wrote: > >The 'hold on a sec' message (HOAS) was discussed some time back in the > RADIUS >world. The reason why it was even desired in that space was that the > protocol >provides no reliability whatsoever. A request is acknowledged when > a response >is received, and if the request must traverse a set of proxies, > it is >difficult to actually know whether the request was ever delivered. If > the end >server had a slow database lookup, it would cause the NAS to > retransmit the >request. > > From owner-aaa-bof@merit.edu Thu Mar 2 10:51:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21157 for ; Thu, 2 Mar 2000 10:51:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 39DD55DDE2; Thu, 2 Mar 2000 10:51:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 27C505DDFD; Thu, 2 Mar 2000 10:51:36 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id D1BF85DDE2 for ; Thu, 2 Mar 2000 10:51:34 -0500 (EST) Received: from pcrperlman (IDENT:root@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id HAA19668; Thu, 2 Mar 2000 07:51:23 -0800 (PST) (envelope-from perl@lucent.com) Message-Id: <4.2.2.20000302104031.00abc560@mail.yikes.com> X-Sender: rdp@mail.yikes.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 02 Mar 2000 10:50:49 +0800 To: "pcalhoun@eng.sun.com" From: Richard Perlman Subject: Re: Revised Network Access Requirements doc (Fwd) Cc: "pcalhoun@eng.sun.com" , Tom =?iso-8859-1?Q?Weckstr=F6m?= , aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" <4.2.2.20000302090907.00a9d240@mail.yikes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat: In the RAS world there tends to be a known action for each set of input parameters. For example, if I get a request that starts with IPASS/... I know I have to send it to iPass and that they typically take 500ms. Or. if the realm is "uzbekistan-online" it may need 4000ms. Or, more simply, If I have a good idea that I need extra time, I'd like to be able to tell the NAS. In the RADIUS world, that would mean fewer retrys. Given the undefined nature of AAAng I am not sure what it would mean. And, as you point out, it might not be necessary given the design of the new protocol.. So, could we say something like "The protocol MUST make allowance for a client and the initial server to reduce timeouts and re-transmissions where long round-trip times can be predicted." Richard At 07:11 AM 03/02/2000 -0800, pcalhoun@eng.sun.com wrote: > > Pat: > > > > The main need I am aware of is determining the time the client (NAS) will > > wait for a reply. The HOAS message would OPTIONALLY be sent to the NAS > > from the first AAA server to the client. Presumably the first AAA server > > could make some determination that the request would require some amount > > of extra time (the definition of extra is an implementation issue). > > > > To put it another way, this is a way for the initial AAA server to send a > > timeout override message to the client. > >But in a complex and convoluted proxy chain arrangement, how would the first >hop even know how long to tell the client to wait? I think in the RADIUS >world, this was ONE way to try to slow down the retramissions from the NAS, >but I'm not convinced that the AAA protocol would suffer from the same flaws >that would require that include HOAS as well. From owner-aaa-bof@merit.edu Fri Mar 3 06:27:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA08818 for ; Fri, 3 Mar 2000 06:27:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id C72E65DD9A; Fri, 3 Mar 2000 06:26:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B57975DD9B; Fri, 3 Mar 2000 06:26:43 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 7F5C15DD9A for ; Fri, 3 Mar 2000 06:26:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22448; Fri, 3 Mar 2000 06:26:41 -0500 (EST) Message-Id: <200003031126.GAA22448@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-acct-01.txt Date: Fri, 03 Mar 2000 06:26:40 -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Introduction to Accounting Management Author(s) : B. Aboba, J. Arkko, D. Harrington Filename : draft-ietf-aaa-acct-01.txt Pages : 47 Date : 02-Mar-00 The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems. Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application. This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, draft-ietf-aaa-accounting-attributes-0x.txt, reviews the state of the art in accounting attributes and record formats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-acct-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-acct-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-acct-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000302145750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-aaa-acct-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-aaa-acct-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000302145750.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Fri Mar 3 10:42:56 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12261 for ; Fri, 3 Mar 2000 10:42:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBA545DD9E; Fri, 3 Mar 2000 10:42:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C8F465DDAA; Fri, 3 Mar 2000 10:42:32 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-38.ricochet.net [206.253.202.38]) by segue.merit.edu (Postfix) with ESMTP id B01A75DD9E for ; Fri, 3 Mar 2000 10:42:28 -0500 (EST) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id HAA61798 for ; Fri, 3 Mar 2000 07:32:36 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: AAA WG Last Call on draft-ietf-aaa-acct-01.txt Date: Fri, 3 Mar 2000 07:42:17 -0800 Message-ID: <01ab01bf8527$0fca7b10$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk This is the AAA Working Group last call on draft-ietf-aaa-acct-01.txt before sending it on to IETF Last Call. This draft is recommended for Informational status. If you have comments on it, please send them to the authors or to the aaa-wg@merit.edu mailing list BEFORE March 18. http://www.ietf.org/internet-drafts/draft-ietf-aaa-acct-01.txt From owner-aaa-bof@merit.edu Fri Mar 3 23:19:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA24492 for ; Fri, 3 Mar 2000 23:19:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7AE0D5DDB4; Fri, 3 Mar 2000 23:19:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5FDCA5DD90; Fri, 3 Mar 2000 23:19:23 -0500 (EST) Received: from mail.kockw.com (unknown [193.188.163.13]) by segue.merit.edu (Postfix) with ESMTP id E2D895DD8C for ; Fri, 3 Mar 2000 23:18:41 -0500 (EST) Received: by mail.kockw.com with Internet Mail Service (5.5.2650.21) id ; Sat, 4 Mar 2000 07:12:47 +0300 Message-ID: <3E3B38E70F82D311A0730004AC38691891E8A4@mail.kockw.com> From: "Chapman, Terrance" To: Internet-Drafts@ietf.org Cc: aaa-wg@merit.edu Subject: RE: I-D ACTION:draft-ietf-aaa-acct-01.txt Date: Sat, 4 Mar 2000 07:12:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk Help! My mailbox is drowning under a sea of drafts! How Can I keep up with what's new in my interest (and competency) areas without getting every single mailing about everything! Terrance Chapman. > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Fri, March 03, 2000 2:27 PM > Cc: aaa-wg@merit.edu > Subject: I-D ACTION:draft-ietf-aaa-acct-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Authentication, Authorization and > Accounting Working Group of the IETF. > > Title : Introduction to Accounting Management > Author(s) : B. Aboba, J. Arkko, D. Harrington > Filename : draft-ietf-aaa-acct-01.txt > Pages : 47 > Date : 02-Mar-00 > > The field of Accounting Management is concerned with the collection of > resource consumption data for the purposes of capacity and trend > analysis, cost allocation, auditing, and billing. This document > describes each of these problems, and discusses the issues involved in > design of modern accounting systems. > > Since accounting applications do not have uniform security and > reliability requirements, it is not possible to devise a single > accounting protocol and set of security services that will meet all > needs. Thus the goal of accounting management is to provide a set of > tools that can be used to meet the requirements of each application. > This document describes the currently available tools as well as the > state of the art in accounting protocol design. A companion document, > draft-ietf-aaa-accounting-attributes-0x.txt, reviews the state of the > art in accounting attributes and record formats. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-aaa-acct-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-aaa-acct-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-aaa-acct-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. << Message: Untitled Attachment >> From owner-aaa-bof@merit.edu Mon Mar 6 14:04:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08599 for ; Mon, 6 Mar 2000 14:04:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6FAA55DE0D; Mon, 6 Mar 2000 14:02:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 505EB5DDC9; Mon, 6 Mar 2000 14:02:12 -0500 (EST) Received: from max.phys.uu.nl (max.phys.uu.nl [131.211.32.73]) by segue.merit.edu (Postfix) with ESMTP id 8C26A5DE0D for ; Mon, 6 Mar 2000 14:02:10 -0500 (EST) Received: from [192.168.254.8] (hst36100.phys.uu.nl [131.211.36.100]) by max.phys.uu.nl (8.9.3/8.9.3/hjm) with ESMTP id UAA29763; Mon, 6 Mar 2000 20:02:07 +0100 (MET) Mime-Version: 1.0 X-Sender: delaat@mail.phys.uu.nl Message-Id: Date: Mon, 6 Mar 2000 19:56:35 +0100 To: aaaarch@fokus.gmd.de, aaa-wg@merit.edu From: "C. de Laat" Subject: Call for RG-meeting on thursday mar 30 at IETF 13h00 - 15h00 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA08599 Hi, We (the chairs of the RG) formally call for the second RG-meeting to take place at the IETF in Adelaide on thursday march 30th from 13h00 until 15h00 as scheduled on the agenda of the IETF. Date and time may change if the ietf changes the agenda. Please note that today march 6th the preregistration for the ietf ends. Also note that the AAA-WG meeting is scheduled on thursday 15h30 - 17h30 and friday 9h00 - 11h30 http://www.ietf.org/meetings/agenda.txt Info on the charter and ongoing work, drafts, mailing list etc. can be found at http://www.phys.uu.nl/~wwwfi/aaaarch We propose to have two goals with this meeting: - discuss/present our newest work amongs us and present to other people - have presentations of other WG's on topics where we need input or information excange We think that short presentations on the following topics would be very welcome from the relevant WG's: - policy framework/language definition - VOIP - applications from our own topics we should at least have on the agenda: - accounting - certificates Please add/delete/suggest speakers/topics before next wednesday's teleconference. Agenda bashing is on, so please correct add/delete and contribute to the agenda. I will publish the preliminary agenda based on received feedback probably next friday. Best regards, Cees. P.S. To be allowed to sit on the front two rows the participants are required to read the charter and the 4 drafts relevant to this group: [1] Vollbrecht, John, et al, "AAA Authorization Framework", draft-irtf-aaaarch-authorization-framework-00.txt, Januari 2000. http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-authorization-framework-00.txt [2] Vollbrecht, John, et al, "AAA Authorization Application Examples", draft-irtf-aaaarch-authorization-apps-00.txt, Januari 2000. http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-authorization-apps-00.txt [3] Vollbrecht, John, et al, "AAA Authorization Requirements", draft-irtf-aaaarch-authorization-reqs-00.txt, Januari 2000. http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-authorization-reqs-00.txt [4] de Laat, Cees, et al, "Generic AAA Architecture", draft-irtf-aaaarch-generic-00.txt, Januari 2000 http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-generic-00.txt -- _________________________________________________________________________ dr.ir. C.Th.A.M. de Laat Position work: N 52°05'8.3", E 5°10'1.9", home: N 52°02'14.0" E 005°09'26.7" From owner-aaa-bof@merit.edu Wed Mar 8 14:03:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA18408 for ; Wed, 8 Mar 2000 14:03:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id DAB305DD9C; Wed, 8 Mar 2000 14:02:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BCD845DDEB; Wed, 8 Mar 2000 14:02:20 -0500 (EST) Received: from mail.campuspipeline.com (unknown [206.81.132.105]) by segue.merit.edu (Postfix) with ESMTP id 734135DD9C for ; Wed, 8 Mar 2000 14:02:19 -0500 (EST) Received: from cadbury ([206.81.132.94]) by mail.campuspipeline.com (Netscape Messaging Server 3.62) with SMTP id 157; Wed, 8 Mar 2000 12:00:35 -0700 Message-ID: <06ee01bf8931$237f4790$e601010a@cadbury.in.teamp.com> From: "Vishal Goenka" To: Cc: , , , Subject: Draft on Single Sign-On Architecture Date: Wed, 8 Mar 2000 12:04:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06EB_01BF88F6.77143A90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_06EB_01BF88F6.77143A90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have recently submitted a draft to the IETF on SSO architecture and = would like to present it to the AAA WG to see if this is in tune with = the charter of the WG. The draft is named: =20 draft-goenka-single-sign-on-arch-00.txt Thanks, -Vishal ------=_NextPart_000_06EB_01BF88F6.77143A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have recently submitted a draft to = the IETF on=20 SSO architecture and would like to present it to the AAA WG to see if = this is in=20 tune with the charter of the WG. The draft is named:
  
draft-goenka-single-sign-on-arch-00.txt
 
Thanks,
-Vishal
 
------=_NextPart_000_06EB_01BF88F6.77143A90-- From owner-aaa-bof@merit.edu Thu Mar 9 09:15:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA02754 for ; Thu, 9 Mar 2000 09:15:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E8165DDBC; Thu, 9 Mar 2000 06:28:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3EF935DDD0; Thu, 9 Mar 2000 06:28:33 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id E809A5DDBC for ; Thu, 9 Mar 2000 06:28:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24416; Thu, 9 Mar 2000 06:28:31 -0500 (EST) Message-Id: <200003091128.GAA24416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-accounting-attributes-02.txt Date: Thu, 09 Mar 2000 06:28:30 -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Accounting Attributes and Record Formats Author(s) : N. Brownlee, A. Blount Filename : draft-ietf-aaa-accounting-attributes-02.txt Pages : 31 Date : 08-Mar-00 This draft summarises IETF and ITU-T documents related to Accounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats for Accounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This draft discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-accounting-attributes-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-accounting-attributes-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-accounting-attributes-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000308131612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-aaa-accounting-attributes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-aaa-accounting-attributes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131612.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Sat Mar 11 14:05:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16408 for ; Sat, 11 Mar 2000 14:05:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 785CD5DD8D; Sat, 11 Mar 2000 14:05:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 365395DD8F; Sat, 11 Mar 2000 14:05:36 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-38.ricochet.net [206.253.202.38]) by segue.merit.edu (Postfix) with ESMTP id 9D2635DD8D for ; Sat, 11 Mar 2000 14:05:31 -0500 (EST) Received: from vaiobean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id KAA82719 for ; Sat, 11 Mar 2000 10:55:01 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: Agenda Date: Sat, 11 Mar 2000 11:05:04 -0800 Message-ID: <030501bf8b8c$b61cb440$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <001601bf7fab$81ecd3e0$428939cc@ntdev.microsoft.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Here is the agenda for Adelaide as it stands today: 1. AAA Requirements, draft-ietf-aaa-na-reqts-02.txt 2. Accounting drafts a. draft-ietf-aaa-acct-03.txt b. draft-ietf-aaa-accounting-attributes-02.txt 3. Re-charter discussion 4. IRTF WG report Comments? From owner-aaa-bof@merit.edu Sat Mar 11 14:30:47 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16703 for ; Sat, 11 Mar 2000 14:30:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EECF5DD8F; Sat, 11 Mar 2000 14:30:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8513F5DD92; Sat, 11 Mar 2000 14:30:06 -0500 (EST) Received: from monitor.internaut.com (mg-206253202-38.ricochet.net [206.253.202.38]) by segue.merit.edu (Postfix) with ESMTP id 37EE65DD8F for ; Sat, 11 Mar 2000 14:29:57 -0500 (EST) Received: from vaiobean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id LAA82741 for ; Sat, 11 Mar 2000 11:19:27 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: Detailed AAA agenda (proposed) Date: Sat, 11 Mar 2000 11:29:30 -0800 Message-ID: <030601bf8b90$202a7c70$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Here is the proposed agenda, with time allocations: Authentication, Authorization and Accounting WG (AAA) CHAIRS: Bernard Aboba Paul Krumviede AGENDA: Thursday, March 30 at 1530-1730 =============================== 1530-1540: Opening remarks and draft status 1540-1600: Mobile IP/TIA 45.6 AAA requirements update (Charlie Perkins) 1600-1610: NASREQ AAA requirements update (Dave Mitton) 1610-1710: Network Access Requirements (Bernard Aboba) 1710-1720: Accounting Attributes (Alan Blount, N. Brownlee) 1720-1730: Accounting Management (Bernard Aboba, Jari Arkko) Friday, March 31 at 0900-1130 ============================== 0900-1000: Re-chartering discussion (Bernard Aboba, Paul K.) 1000-1030: IRTF WG Report (J. Vollbrecht, C. de Laat) 1030-1100: Status review and closing remarks From owner-aaa-bof@merit.edu Sun Mar 12 01:34:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA26374 for ; Sun, 12 Mar 2000 01:34:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E37B5DD92; Sun, 12 Mar 2000 01:34:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5DDDE5DD9D; Sun, 12 Mar 2000 01:34:35 -0500 (EST) Received: from mail.r4s.net (adsl-63-197-12-182.dsl.snfc21.pacbell.net [63.197.12.182]) by segue.merit.edu (Postfix) with ESMTP id 5A0415DD92 for ; Sun, 12 Mar 2000 01:34:34 -0500 (EST) Received: from mail.r4s.net (adsl-216-102-65-213.dsl.snfc21.pacbell.net [216.102.65.213]) by mail.r4s.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id GTDXNLHV; Sat, 11 Mar 2000 22:37:16 -0000 From: betty To: aaa-wg@merit.edu Subject: HI ! This is for you ... Reply-To: betty@r4s.net Date: 11 Mar 2000 22:37:16 +0000 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <20000312063434.5A0415DD92@segue.merit.edu> Sender: owner-aaa-bof@merit.edu Precedence: bulk Earn more money using your best skills with http://www.Freelancebank.com ! Freelancebank.com is designed for global Internet freelancers. Your name and profile can be listed for free and you can search for current projects at the top companies. Even more, you can build your own dedicated web site in less than 5 minutes so that corporations can start seeing you and your skills. Come try today. http://www.freelancebank.com From owner-aaa-bof@merit.edu Mon Mar 13 03:53:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA17124 for ; Mon, 13 Mar 2000 03:53:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id B04CC5DDBE; Mon, 13 Mar 2000 03:53:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7750B5DDB2; Mon, 13 Mar 2000 03:53:26 -0500 (EST) Received: from monitor.internaut.com (mg-206191146-3.ricochet.net [206.191.146.3]) by segue.merit.edu (Postfix) with ESMTP id D198F5DDBE for ; Mon, 13 Mar 2000 03:53:19 -0500 (EST) Received: from vaiobean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id AAA84732 for ; Mon, 13 Mar 2000 00:42:42 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: Re-charter discussion Date: Mon, 13 Mar 2000 00:53:21 -0800 Message-ID: <000201bf8cc9$9693d890$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Now that the AAA WG is on its way to completing its milestones and drafts are in last call, it is time to begin a discussion on re-chartering. A proposed strawman charter is given below. Goal is to have a proposed charter ready by 3/31/00. Comments? ===================================================== Authentication, Authorization, and Accounting (AAA) Chairs: Bernard Aboba Paul Krumviede Operations and Management Area Directors: Randy Bush Bert Wijnen Operations and Management Area Advisor: Randy Bush Mailing Lists: General Discussion:aaa-wg@merit.edu To Subscribe: majordomo@merit.edu In Body: subscribe aaa-wg Archive: http://www.merit.edu/mail.archives/html/aaa-wg/ Description of Working Group: The Authentication, Authorization and Accounting Working Group focused on the development of requirements for Authentication, Authorization and Accounting as applied to network access. Requirements were gathered from other Working Groups, such as NASREQ, Mobile IP and ROAMOPS. This incarnation of the AAA Working Group will focus on selection of a AAA protocol to be developed. We will solicit submission of protocols, will evaluate them against the requirements and will decide whether one of them meets the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design one from scratch. In this process, it is to be understood that the IETF does not function as a rubber stamp. A protocol, if accepted, will likely be changed significantly during the process of development. Authors of candidate protocols must be willing to give up change conrol to the IETF, so as to allow modification of the candidate protocols to AAA WG needs. The immediate goals of the AAA working group are to: - Request submission of candidate protocols. - Publish a draft comparing candidate protocols against the requirements. - Decide whether any of the candidate protocols meet the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design a new protocol. Goals and Milestones April 00 - Request submission of candidate protocols May 00 - Produce the first draft of a document comparing the candidates against the requirements August 00 - Select a protocol, or decide to start from scratch. If the former, submit the Protocol Internet-Draft as a WG Work Item. September 00 - working group closes and a new working group is formed to design a new protocol or to finish development of a proposal From owner-aaa-bof@merit.edu Mon Mar 13 08:33:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21406 for ; Mon, 13 Mar 2000 08:33:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7C925DDBE; Mon, 13 Mar 2000 08:32:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9C8D25DE78; Mon, 13 Mar 2000 08:32:02 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 089995DDBE for ; Mon, 13 Mar 2000 08:32:01 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id FAA17067; Mon, 13 Mar 2000 05:22:09 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 13 Mar 2000 13:28:37 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id FAA22756; Mon, 13 Mar 2000 05:28:36 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000313051910.00b1bd50@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 13 Mar 2000 05:29:22 -0800 To: From: Matt Holdrege Subject: Re: Re-charter discussion Cc: In-Reply-To: <000201bf8cc9$9693d890$268939cc@ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk My only comment is that this sounds like an invitation to a beauty contest without a definite set of judges. We have all known about the competitors for some time now. Why do we have to wait til August or later to get started? I think the AAA WG should just choose a protocol in Adelaide and get on with it. Even if we have to hum to make a choice, it's better than the alternative. Dragging things out doesn't help at all. No matter who wins, the losers will be upset and push for their protocol in another WG or another forum. Why is it better to have the losers complain later than sooner? Let's not have a process for process's sake. It buys us nothing. Let's choose a protocol now, spruce it up as needed, call it a standard and get on with life. At 12:53 AM 3/13/00 -0800, Bernard Aboba wrote: >Now that the AAA WG is on its way to completing >its milestones and drafts are in last call, it is >time to begin a discussion on re-chartering. A >proposed strawman charter is given below. Goal is >to have a proposed charter ready by 3/31/00. > >Comments? > >===================================================== >Authentication, Authorization, and Accounting (AAA) > >Chairs: Bernard Aboba > Paul Krumviede > >Operations and Management Area Directors: >Randy Bush >Bert Wijnen > >Operations and Management Area Advisor: >Randy Bush > >Mailing Lists: >General Discussion:aaa-wg@merit.edu >To Subscribe: majordomo@merit.edu >In Body: subscribe aaa-wg >Archive: http://www.merit.edu/mail.archives/html/aaa-wg/ > >Description of Working Group: > >The Authentication, Authorization and Accounting Working Group >focused on the development of requirements for Authentication, >Authorization and Accounting as applied to network access. >Requirements were gathered from other Working Groups, >such as NASREQ, Mobile IP and ROAMOPS. > >This incarnation of the AAA Working Group will focus on >selection of a AAA protocol to be developed. We will solicit >submission of protocols, will evaluate them against the requirements >and will decide whether one of them meets the requirements >sufficiently to become the basis of the subsequent design >phase, or whether it is necessary to design one from scratch. > >In this process, it is to be understood that the >IETF does not function as a rubber stamp. A protocol, >if accepted, will likely be changed significantly >during the process of development. > >Authors of candidate protocols must be willing to give >up change conrol to the IETF, so as to allow modification >of the candidate protocols to AAA WG needs. > >The immediate goals of the AAA working group are to: > >- Request submission of candidate protocols. > >- Publish a draft comparing candidate protocols against > the requirements. > >- Decide whether any of the candidate protocols meet the > requirements sufficiently to become the basis of the > subsequent design phase, or whether it is necessary to > design a new protocol. > >Goals and Milestones > >April 00 - Request submission of candidate protocols > >May 00 - Produce the first draft of a document comparing > the candidates against the requirements > >August 00 - Select a protocol, or decide to start from > scratch. If the former, submit the Protocol > Internet-Draft as a WG Work Item. > >September 00 - working group closes and a new working > group is formed to design a new protocol > or to finish development of a proposal From owner-aaa-bof@merit.edu Mon Mar 13 11:29:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24340 for ; Mon, 13 Mar 2000 11:29:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 76BF15DDB5; Mon, 13 Mar 2000 11:29:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 65DAC5DD9D; Mon, 13 Mar 2000 11:29:31 -0500 (EST) Received: from smtpgw2.sprintspectrum.com (smtpgw2.sprintspectrum.com [208.18.119.43]) by segue.merit.edu (Postfix) with ESMTP id B5A075DD9A for ; Mon, 13 Mar 2000 11:29:29 -0500 (EST) Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id KAA16500; Mon, 13 Mar 2000 10:21:02 -0600 (CST) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Mar 2000 10:21:02 -0600 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC883A1298@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'Matt Holdrege'" , aboba@internaut.com Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion Date: Mon, 13 Mar 2000 10:20:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I fully support Matt's comments. Let make a decision and start working on the Protocol. The longer we wait the worse it is on those of us wanting to deploy services the need it. Mark A. Lipford Manager, Wireless Industry Standards - Data Sprint PCS 8001 College Blvd.; Suite 210 Overland Park, KS 66210 (913) 664-8335 (office) (913) 664-8440 (fax) (913) 226-9060 (PCS) -----Original Message----- From: Matt Holdrege [mailto:holdrege@lucent.com] Sent: Monday, March 13, 2000 7:29 AM To: aboba@internaut.com Cc: aaa-wg@merit.edu Subject: Re: Re-charter discussion My only comment is that this sounds like an invitation to a beauty contest without a definite set of judges. We have all known about the competitors for some time now. Why do we have to wait til August or later to get started? I think the AAA WG should just choose a protocol in Adelaide and get on with it. Even if we have to hum to make a choice, it's better than the alternative. Dragging things out doesn't help at all. No matter who wins, the losers will be upset and push for their protocol in another WG or another forum. Why is it better to have the losers complain later than sooner? Let's not have a process for process's sake. It buys us nothing. Let's choose a protocol now, spruce it up as needed, call it a standard and get on with life. At 12:53 AM 3/13/00 -0800, Bernard Aboba wrote: >Now that the AAA WG is on its way to completing >its milestones and drafts are in last call, it is >time to begin a discussion on re-chartering. A >proposed strawman charter is given below. Goal is >to have a proposed charter ready by 3/31/00. > >Comments? > >===================================================== >Authentication, Authorization, and Accounting (AAA) > >Chairs: Bernard Aboba > Paul Krumviede > >Operations and Management Area Directors: >Randy Bush >Bert Wijnen > >Operations and Management Area Advisor: >Randy Bush > >Mailing Lists: >General Discussion:aaa-wg@merit.edu >To Subscribe: majordomo@merit.edu >In Body: subscribe aaa-wg >Archive: http://www.merit.edu/mail.archives/html/aaa-wg/ > >Description of Working Group: > >The Authentication, Authorization and Accounting Working Group >focused on the development of requirements for Authentication, >Authorization and Accounting as applied to network access. >Requirements were gathered from other Working Groups, >such as NASREQ, Mobile IP and ROAMOPS. > >This incarnation of the AAA Working Group will focus on >selection of a AAA protocol to be developed. We will solicit >submission of protocols, will evaluate them against the requirements >and will decide whether one of them meets the requirements >sufficiently to become the basis of the subsequent design >phase, or whether it is necessary to design one from scratch. > >In this process, it is to be understood that the >IETF does not function as a rubber stamp. A protocol, >if accepted, will likely be changed significantly >during the process of development. > >Authors of candidate protocols must be willing to give >up change conrol to the IETF, so as to allow modification >of the candidate protocols to AAA WG needs. > >The immediate goals of the AAA working group are to: > >- Request submission of candidate protocols. > >- Publish a draft comparing candidate protocols against > the requirements. > >- Decide whether any of the candidate protocols meet the > requirements sufficiently to become the basis of the > subsequent design phase, or whether it is necessary to > design a new protocol. > >Goals and Milestones > >April 00 - Request submission of candidate protocols > >May 00 - Produce the first draft of a document comparing > the candidates against the requirements > >August 00 - Select a protocol, or decide to start from > scratch. If the former, submit the Protocol > Internet-Draft as a WG Work Item. > >September 00 - working group closes and a new working > group is formed to design a new protocol > or to finish development of a proposal From owner-aaa-bof@merit.edu Mon Mar 13 17:31:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA01198 for ; Mon, 13 Mar 2000 17:31:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 408D25DDD7; Mon, 13 Mar 2000 17:29:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 278315DDD8; Mon, 13 Mar 2000 17:29:58 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by segue.merit.edu (Postfix) with ESMTP id 9213E5DDD7 for ; Mon, 13 Mar 2000 17:29:55 -0500 (EST) Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by smtprtp1.ntcom.nortel.net; Mon, 13 Mar 2000 17:29:24 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Mar 2000 17:29:24 -0500 Message-ID: <2FBDE67DDFC0D11190050000F8BCCC9C02541297@zrtpd00p.us.nortel.com> From: "Gopal Iyengar" To: "'aboba'" , aaa-wg Subject: RE: Re-charter discussion Date: Mon, 13 Mar 2000 17:29:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8D3B.9565D42E" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8D3B.9565D42E Content-Type: text/plain I would like to suggest one minor change in the first paragraph as shown below. Since the requirements were gathered from four specific network access methods, why not be specific and list all 4. The present text seem to indicate that requirements were gathered from many WGs (The qualifier 'such as' gives the impression that many other application requirements were involved). However as you may recall the scope of the AAA WG was limited to look at only the four access method (NASREQ, ROAMOPS, Mobile-IP and CDMA-2000) Gopal Iyengar > -----Original Message----- > From: Bernard Aboba [SMTP:aboba@internaut.com] > Sent: Monday, March 13, 2000 3:53 AM > To: aaa-wg > Subject: Re-charter discussion > > Now that the AAA WG is on its way to completing > its milestones and drafts are in last call, it is > time to begin a discussion on re-chartering. A > proposed strawman charter is given below. Goal is > to have a proposed charter ready by 3/31/00. > > Comments? > > ===================================================== > Authentication, Authorization, and Accounting (AAA) > > Chairs: Bernard Aboba > Paul Krumviede > > Operations and Management Area Directors: > Randy Bush > Bert Wijnen > > Operations and Management Area Advisor: > Randy Bush > > Mailing Lists: > General Discussion:aaa-wg@merit.edu > To Subscribe: majordomo@merit.edu > In Body: subscribe aaa-wg > Archive: http://www.merit.edu/mail.archives/html/aaa-wg/ > > Description of Working Group: > > The Authentication, Authorization and Accounting Working Group > focused on the development of requirements for Authentication, > Authorization and Accounting as applied to network access. > Requirements were gathered from > NASREQ, Mobile IP, ROAMOPS IETF WGs and CDMA2000 developed by TIA TR45.7. > This incarnation of the AAA Working Group will focus on > selection of a AAA protocol to be developed. We will solicit > submission of protocols, will evaluate them against the requirements > and will decide whether one of them meets the requirements > sufficiently to become the basis of the subsequent design > phase, or whether it is necessary to design one from scratch. > > In this process, it is to be understood that the > IETF does not function as a rubber stamp. A protocol, > if accepted, will likely be changed significantly > during the process of development. > > Authors of candidate protocols must be willing to give > up change conrol to the IETF, so as to allow modification > of the candidate protocols to AAA WG needs. > > The immediate goals of the AAA working group are to: > > - Request submission of candidate protocols. > > - Publish a draft comparing candidate protocols against > the requirements. > > - Decide whether any of the candidate protocols meet the > requirements sufficiently to become the basis of the > subsequent design phase, or whether it is necessary to > design a new protocol. > > Goals and Milestones > > April 00 - Request submission of candidate protocols > > May 00 - Produce the first draft of a document comparing > the candidates against the requirements > > August 00 - Select a protocol, or decide to start from > scratch. If the former, submit the Protocol > Internet-Draft as a WG Work Item. > > September 00 - working group closes and a new working > group is formed to design a new protocol > or to finish development of a proposal > ------_=_NextPart_001_01BF8D3B.9565D42E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Re-charter discussion

I would like to = suggest one minor change in the first paragraph as shown below. Since = the requirements were gathered from four specific network access = methods, why not be specific and list all 4. The present text seem to = indicate that requirements were gathered from many WGs (The qualifier = 'such as' gives the impression that many other application requirements = were involved). However as you may recall the scope of the AAA WG was = limited to look at only the four access method (NASREQ, ROAMOPS, = Mobile-IP and CDMA-2000)

Gopal Iyengar

    -----Original Message-----
    From:   Bernard Aboba [SMTP:aboba@internaut.com]
    Sent:   Monday, March 13, 2000 3:53 AM
    To:     aaa-wg
    Subject:       = Re-charter discussion

    Now that the AAA WG is on its way to = completing
    its milestones and drafts are in last = call, it is
    time to begin a discussion on = re-chartering. A
    proposed strawman charter is given = below. Goal is
    to have a proposed charter ready by = 3/31/00.

    Comments?

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Authentication, Authorization, and = Accounting (AAA)

    Chairs: Bernard Aboba = <aboba@internaut.com>
            Paul = Krumviede <paul@mci.net>

    Operations and Management Area = Directors:
    Randy Bush = <randy@psg.com>
    Bert Wijnen = <bwijnen@lucent.com>

    Operations and Management Area = Advisor:
    Randy Bush = <randy@psg.com>

    Mailing Lists:
    General Discussion:aaa-wg@merit.edu =
    To Subscribe: majordomo@merit.edu =
    In Body: subscribe aaa-wg
    Archive: http://www.merit.edu/mail.archives/html/aaa-wg/

    Description of Working Group:

    The Authentication, Authorization and = Accounting Working Group
    focused on the development of = requirements for Authentication,
    Authorization and Accounting as = applied to network access.
    Requirements were gathered from  =
    NASREQ, Mobile IP, ROAMOPS IETF WGs and CDMA2000 developed by TIA TR45.7.
    This incarnation of the AAA Working = Group will focus on
    selection of a AAA protocol to be = developed. We will solicit
    submission of protocols, will = evaluate them against the requirements
    and will decide whether one of them = meets the requirements
    sufficiently to become the basis of = the subsequent design
    phase, or whether it is necessary to = design one from scratch.
     
    In this process, it is to be = understood that the
    IETF does not function as a rubber = stamp. A protocol,
    if accepted, will likely be changed = significantly
    during the process of = development.

    Authors of candidate protocols must be = willing to give
    up change conrol to the IETF, so as = to allow modification
    of the candidate protocols to AAA WG = needs.

    The immediate goals of the AAA working = group are to:

    - Request submission of candidate = protocols.

    - Publish a draft comparing candidate = protocols against
      the requirements.

    - Decide whether any of the candidate = protocols meet the
      requirements sufficiently to = become the basis of the
      subsequent design phase, or = whether it is necessary to
      design a new protocol.

    Goals and Milestones

    April 00 - Request submission of = candidate protocols

    May 00 - Produce the first draft of a = document comparing
             the = candidates against the requirements

    August 00 - Select a protocol, or = decide to start from
             &nb= sp;  scratch. If the former, submit the Protocol
             &nb= sp;  Internet-Draft as a WG Work Item.

    September 00 - working group closes = and a new working
             &nb= sp;  group is formed to design a new protocol
             &nb= sp;  or to finish development of a proposal

------_=_NextPart_001_01BF8D3B.9565D42E-- From owner-aaa-bof@merit.edu Tue Mar 14 10:18:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14824 for ; Tue, 14 Mar 2000 10:18:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6942A5DD9C; Tue, 14 Mar 2000 10:16:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4970B5DE10; Tue, 14 Mar 2000 10:16:51 -0500 (EST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by segue.merit.edu (Postfix) with ESMTP id 372E85DD9C for ; Tue, 14 Mar 2000 10:16:49 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id KAA13239 for ; Tue, 14 Mar 2000 10:11:19 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdQAArOGKa_; Tue Mar 14 10:11:15 2000 Received: from [138.120.49.10] by kanata-mh1.ca.newbridge.com with ESMTP for aaa-wg@merit.edu; Tue, 14 Mar 2000 10:16:41 -0500 Received: (from smap@localhost) by affserver.ca.newbridge.com. (8.8.5/8.8.5) id KAA15072 for ; Tue, 14 Mar 2000 10:17:05 -0500 (EST) Received: from mail-router.bridgewatersys.com(192.168.150.1) by affserver via smap (V1.3) id sma015068; Tue Mar 14 10:16:47 2000 Received: from mjones by bridgewatersys.com (SMI-8.6/SMI-SVR4) id KAA19516; Tue, 14 Mar 2000 10:14:57 -0500 From: "Mark Jones" To: Subject: RE: Re-charter discussion Date: Tue, 14 Mar 2000 10:18:46 -0500 Message-Id: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.2.2.20000313051910.00b1bd50@porky> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Well said, Matt. The need for a decision on the AAA base protocol is urgent for more than one IETF (and non-IETF) WG. Waiting another six months increases the chance that these different groups will be compelled to give up on the AAA WG and make their own potentially different decisions. Looking through the AAA/NASREQ/MobileIP/ROAMOPS WG, I see drafts documenting the requirements, the candidates and their relative merits. Can these drafts be used as the basis for selecting a protocol in Adelaide? Even if the general consensus is to build a new protocol from scratch, an interim AAA base protocol is still needed. RADIUS is over-stretched already. BTW, if a new protocol is the chosen route, please don't even think of calling it CIRCUMFERENCE ;-) Regards, Mark From owner-aaa-bof@merit.edu Tue Mar 14 18:49:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA06566 for ; Tue, 14 Mar 2000 18:49:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id E566D5DDDE; Tue, 14 Mar 2000 18:47:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C44A35DDF0; Tue, 14 Mar 2000 18:47:58 -0500 (EST) Received: from monitor.internaut.com (mg-206191146-3.ricochet.net [206.191.146.3]) by segue.merit.edu (Postfix) with ESMTP id 8FA925DDDE for ; Tue, 14 Mar 2000 18:47:53 -0500 (EST) Received: from vaiobean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id PAA86862 for ; Tue, 14 Mar 2000 15:37:02 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: RE: Re-charter discussion Date: Tue, 14 Mar 2000 15:47:46 -0800 Message-ID: <01af01bf8e0f$b4832350$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Some thoughts on the milestones: >April 00 - Request submission of candidate protocols Looks like the earliest we can get re-chartered is April (assuming we get the charter done by 3/31) so that it's hard to see how this one can be moved up. >May 00 - Produce the first draft of a document comparing > the candidates against the requirements Assuming that we leverage existing work, and take some time to extend it into a full comparison document, it seems reasonable to have a first draft within a few weeks. If people want to move this one up, the best way is to volunteer to work on the comparison document and put in the time to get it finished. >August 00 - Select a protocol. It's expected that there will be considerable discussion occurring between the time when the first draft of the comparison document is released and when the WG is ready to select a protocol. In the IETF there is no penalty for finishing early, so that if the WG comes to consensus before then, great. In order to help that process along, it may make sense to have an interim meeting (perhaps in the June timeframe?). From owner-aaa-bof@merit.edu Wed Mar 15 09:18:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19868 for ; Wed, 15 Mar 2000 09:18:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id B88705DDE9; Wed, 15 Mar 2000 09:15:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9C7EE5DDED; Wed, 15 Mar 2000 09:15:46 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 1A5A15DDE9 for ; Wed, 15 Mar 2000 09:15:45 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id GAA27383; Wed, 15 Mar 2000 06:05:52 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 Mar 2000 14:12:21 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id GAA08641; Wed, 15 Mar 2000 06:12:20 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000315060422.00b5d220@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 06:13:16 -0800 To: From: Matt Holdrege Subject: RE: Re-charter discussion Cc: In-Reply-To: <01af01bf8e0f$b4832350$268939cc@ntdev.microsoft.com> References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 03:47 PM 3/14/00 -0800, Bernard Aboba wrote: >Some thoughts on the milestones: > >August 00 - Select a protocol. > >It's expected that there will be considerable discussion >occurring between the time when the first draft of the >comparison document is released and when the WG is >ready to select a protocol. In the IETF there is no >penalty for finishing early, so that if the WG comes >to consensus before then, great. In order to help that >process along, it may make sense to have an interim >meeting (perhaps in the June timeframe?). This is where the problem is. We have already had over a year of discussion about the candidate protocols and the requirements. True that discussion has not occured in a formal WG, but it has happened. What is the point of continuing? I understand we have to follow formal IETF processes to produce a standard, but I don't think we have to rehash all the previous discussions on this topic. If we have a unanimous choice for an AAA protocol, then we needn't waste any time selecting it. If we have a fight between two or more protocols, nothing is going to happen between now and June to change peoples attitudes. So let's get it on now! For newbies, my evident frustration is borne from years of AAA feet dragging in the IETF. We could have and should have solved this long ago. From owner-aaa-bof@merit.edu Wed Mar 15 10:06:18 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20503 for ; Wed, 15 Mar 2000 10:06:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 066C55DDE9; Wed, 15 Mar 2000 10:05:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0C0905DDE8; Wed, 15 Mar 2000 10:05:30 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 926165DE0F for ; Wed, 15 Mar 2000 10:05:24 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12VFMQ-000DTf-00; Wed, 15 Mar 2000 07:05:22 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> Message-Id: Date: Wed, 15 Mar 2000 07:05:22 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk > This is where the problem is. We have already had over a year of discussion > about the candidate protocols and the requirements. True that discussion > has not occured in a formal WG, but it has happened. it also did not happen in the presence of agreed criteria. randy From owner-aaa-bof@merit.edu Wed Mar 15 10:11:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20548 for ; Wed, 15 Mar 2000 10:11:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E58365DDF1; Wed, 15 Mar 2000 10:10:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D00C95DDED; Wed, 15 Mar 2000 10:10:49 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 57C9D5DDE8 for ; Wed, 15 Mar 2000 10:10:48 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id HAA04615; Wed, 15 Mar 2000 07:04:17 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 Mar 2000 15:10:46 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id HAA25476; Wed, 15 Mar 2000 07:10:46 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000315070845.00b4fb10@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 07:10:38 -0800 To: Randy Bush From: Matt Holdrege Subject: RE: Re-charter discussion Cc: aaa-wg@merit.edu In-Reply-To: References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:05 AM 3/15/00 -0800, Randy Bush wrote: > > This is where the problem is. We have already had over a year of > discussion > > about the candidate protocols and the requirements. True that discussion > > has not occured in a formal WG, but it has happened. > >it also did not happen in the presence of agreed criteria. Well we have the criteria now (don't we?) so why can't we begin the debate? Adelaide is the perfect place to start this as we can handle it face-2-face to avoid misunderstandings. From owner-aaa-bof@merit.edu Wed Mar 15 10:26:35 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21000 for ; Wed, 15 Mar 2000 10:26:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id D23D55DD8C; Wed, 15 Mar 2000 10:26:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B121D5DDED; Wed, 15 Mar 2000 10:26:10 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id D35CF5DD8C for ; Wed, 15 Mar 2000 10:26:08 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12VFgR-000DZq-00; Wed, 15 Mar 2000 07:26:03 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> <4.2.2.20000315070845.00b4fb10@porky> Message-Id: Date: Wed, 15 Mar 2000 07:26:03 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk >>> This is where the problem is. We have already had over a year of >>> discussion about the candidate protocols and the requirements. True >>> that discussion has not occured in a formal WG, but it has happened. >> it also did not happen in the presence of agreed criteria. > Well we have the criteria now (don't we?) so why can't we begin the > debate? Adelaide is the perfect place to start this as we can handle it > face-2-face to avoid misunderstandings. formally, we do not have the criteria until the draft progresses to an rfc. but there does not seem to be a major uproar about it. while we can discuss this in adelaide, let us not forget that the mailing list is the real venue of the wg. the proof of the pudding will be what the wg actually does, not what the written milestones are. all in all, wgs do not have a long record of beating milestones. the milestones are constrained by varying views of reality, but also the procedural aspects of the ietf process. i.e., just due to the adelaide meeting and new work notification requirements, i am not sure we can have a new charter formally accepted in april. of course this need not prevent useful work from happening. of course we can spend the time discussing the schedule as opposed to progressing on it. talk is cheap. what candidates are there? how goes an update of the current comparison draft? randy From owner-aaa-bof@merit.edu Wed Mar 15 10:34:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21168 for ; Wed, 15 Mar 2000 10:34:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0409F5DE3E; Wed, 15 Mar 2000 10:33:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E7B5F5DE3D; Wed, 15 Mar 2000 10:33:30 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 693A45DDF1 for ; Wed, 15 Mar 2000 10:33:29 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id HAA07651; Wed, 15 Mar 2000 07:26:57 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 Mar 2000 15:33:26 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id HAA01698; Wed, 15 Mar 2000 07:33:25 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000315073132.00b70ba0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 07:33:09 -0800 To: Randy Bush From: Matt Holdrege Subject: RE: Re-charter discussion Cc: aaa-wg@merit.edu In-Reply-To: References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> <4.2.2.20000315070845.00b4fb10@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:26 AM 3/15/00 -0800, Randy Bush wrote: >what candidates are there? Good point. Can we ask (formally if necessary) the authors of any AAA protocol that thinks they meet the current requirements to stand up and raise their hand? From owner-aaa-bof@merit.edu Wed Mar 15 10:41:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21226 for ; Wed, 15 Mar 2000 10:41:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A5C25DDE8; Wed, 15 Mar 2000 10:41:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3672C5DDED; Wed, 15 Mar 2000 10:41:19 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 1BC7F5DDE8 for ; Wed, 15 Mar 2000 10:41:18 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12VFv7-000DeN-00; Wed, 15 Mar 2000 07:41:13 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> <4.2.2.20000315070845.00b4fb10@porky> <4.2.2.20000315073132.00b70ba0@porky> Message-Id: Date: Wed, 15 Mar 2000 07:41:13 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk >> what candidates are there? > Good point. Can we ask (formally if necessary) the authors of any AAA > protocol that thinks they meet the current requirements to stand up and > raise their hand? perhaps, in the spirit of the ietf's openness, the wg might ask more widely and maybe a bit more formally. i.e. the wg might draft a message to be posted to the ieft list, and ask the secretariat to carry it to the other standards groups with which the ietf has liaison. it might tell of the requirements draft(s), explain their status, and solicit candidate protocols. along this line, if the drafts are ready to progress, we should move them through the process. the adelaide meeting means the iesg misses two telechats where we can progress documents. so we want this stuff on the agenda as soon as reasonably possible. randy From owner-aaa-bof@merit.edu Wed Mar 15 10:51:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21359 for ; Wed, 15 Mar 2000 10:51:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1DE95DDF7; Wed, 15 Mar 2000 10:51:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE8565DDED; Wed, 15 Mar 2000 10:51:24 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 30B6D5DDF1 for ; Wed, 15 Mar 2000 10:51:23 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id HAA09886; Wed, 15 Mar 2000 07:44:49 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 Mar 2000 15:51:18 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id HAA06756; Wed, 15 Mar 2000 07:51:17 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000315074322.00b67690@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 07:50:56 -0800 To: Randy Bush From: Matt Holdrege Subject: RE: Re-charter discussion Cc: aaa-wg@merit.edu In-Reply-To: References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> <4.2.2.20000315070845.00b4fb10@porky> <4.2.2.20000315073132.00b70ba0@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:41 AM 3/15/00 -0800, Randy Bush wrote: > >> what candidates are there? > > Good point. Can we ask (formally if necessary) the authors of any AAA > > protocol that thinks they meet the current requirements to stand up and > > raise their hand? > >perhaps, in the spirit of the ietf's openness, the wg might ask more widely >and maybe a bit more formally. i.e. the wg might draft a message to be >posted to the ieft list, and ask the secretariat to carry it to the other >standards groups with which the ietf has liaison. it might tell of the >requirements draft(s), explain their status, and solicit candidate >protocols. Sounds good. Formally I don't think the IETF has any liaisons, but ISOC can liaise with the ITU and certain other fora. However this kind of activity takes a good bit of effort and we can't assume that the Secretariat will know what to do. So we need a bit of a plan. I'd be happy to help. We also need to set timelines so we don't get held up with meeting schedules of other fora. That can easily drag things out for months. Realistically I think we can assume that the AAA leaders of those other groups are on this email list. I know this to be true for many of them. It's well understood that the IETF creates IP protocols. >along this line, if the drafts are ready to progress, we should move them >through the process. the adelaide meeting means the iesg misses two >telechats where we can progress documents. so we want this stuff on the >agenda as soon as reasonably possible. Yes. I don't know what if anything is holding this process up now. From owner-aaa-bof@merit.edu Wed Mar 15 10:59:29 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21466 for ; Wed, 15 Mar 2000 10:59:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 706F55DDED; Wed, 15 Mar 2000 10:59:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5DAD15DDE9; Wed, 15 Mar 2000 10:59:08 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 366EB5DDED for ; Wed, 15 Mar 2000 10:59:07 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12VGCP-000DkI-00; Wed, 15 Mar 2000 07:59:05 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> <4.2.2.20000315070845.00b4fb10@porky> <4.2.2.20000315073132.00b70ba0@porky> <4.2.2.20000315074322.00b67690@porky> Message-Id: Date: Wed, 15 Mar 2000 07:59:05 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk > Formally I don't think the IETF has any liaisons we do > However this kind of activity takes a good bit of effort and we can't > assume that the Secretariat will know what to do. i assure you that it is extremely safe assume it. > We also need to set timelines so we don't get held up with meeting > schedules of other fora. That can easily drag things out for months. again, you are wrapping yourself, and us with you, around perceived issues with other people's processes. instead of telling us what problems you think others will have, how about just doing a first draft of the solicitation? > Yes. I don't know what if anything is holding this process up now. imiho, talking about the wrong things. randy From owner-aaa-bof@merit.edu Wed Mar 15 11:49:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA22645 for ; Wed, 15 Mar 2000 11:49:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C0C75DD8C; Wed, 15 Mar 2000 11:49:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 552975DDEC; Wed, 15 Mar 2000 11:49:13 -0500 (EST) Received: from smtpgw2.sprintspectrum.com (smtpgw2.sprintspectrum.com [208.18.119.43]) by segue.merit.edu (Postfix) with ESMTP id 530765DD8C for ; Wed, 15 Mar 2000 11:49:07 -0500 (EST) Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id KAA23164; Wed, 15 Mar 2000 10:48:26 -0600 (CST) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 10:48:26 -0600 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC883A12C6@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'Matt Holdrege'" , Randy Bush Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion Date: Wed, 15 Mar 2000 10:48:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I have been watching these last few exchanges go back and forth. I agree that we need a "formal" set of requirements before we can start the discussion. Based on the response that I have seen (or not seen) on this list on the requirements I-D I believe we have a very stable list of requirements and recommend we DO start the discussion in Adelaide. I think it is a well understood process that development in general will usually start on new products (or protocols) prior to having a formalized requirements document. I say we do the same thing. We have a very stable document that simply needs to have an RFC number attached to it (I know there is more to it then that), but the essence of the document will not be changed. Let's have the re-charter discussion in Adelaide and let's kick-off the protocol debate. One of the responses on this thread indicated a need to start working on a comparison document. Let's start that. As a user of the service I would be happy to assist in providing a "users" thoughts on the protocols, but to date I know of only one protocol out there sitting and waiting, if there are others please make them known so we can get started. I also agree with Matt on a couple of points. If there is agreement in Adelaide on a protocol let's get on with it and not waste time. I too am frustrated at the time this is taking. I need a protocol I can deploy now and RADIUS simply does not meet my needs. I have seen nor heard anything that specifically states we cannot get started in Adelaide (or sooner by e-mail). Mark A. Lipford Manager, Wireless Industry Standards - Data Sprint PCS 8001 College Blvd.; Suite 210 Overland Park, KS 66210 (913) 664-8335 (office) (913) 664-8440 (fax) (913) 226-9060 (PCS) -----Original Message----- From: Matt Holdrege [mailto:holdrege@lucent.com] Sent: Wednesday, March 15, 2000 9:33 AM To: Randy Bush Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion At 07:26 AM 3/15/00 -0800, Randy Bush wrote: >what candidates are there? Good point. Can we ask (formally if necessary) the authors of any AAA protocol that thinks they meet the current requirements to stand up and raise their hand? From owner-aaa-bof@merit.edu Wed Mar 15 12:13:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA23124 for ; Wed, 15 Mar 2000 12:13:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6AA45DE0B; Wed, 15 Mar 2000 12:13:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 872BF5DE3B; Wed, 15 Mar 2000 12:13:20 -0500 (EST) Received: from smtpgw1.sprintspectrum.com (smtpgw1.sprintspectrum.com [208.18.119.44]) by segue.merit.edu (Postfix) with ESMTP id 874245DE0B for ; Wed, 15 Mar 2000 12:13:15 -0500 (EST) Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id LAA28337; Wed, 15 Mar 2000 11:10:53 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 11:10:53 -0600 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC883A12CC@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'Randy Bush'" , Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion Date: Wed, 15 Mar 2000 11:10:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I support this Mark A. Lipford Manager, Wireless Industry Standards - Data Sprint PCS 8001 College Blvd.; Suite 210 Overland Park, KS 66210 (913) 664-8335 (office) (913) 664-8440 (fax) (913) 226-9060 (PCS) -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, March 15, 2000 9:41 AM To: Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion >> what candidates are there? > Good point. Can we ask (formally if necessary) the authors of any AAA > protocol that thinks they meet the current requirements to stand up and > raise their hand? perhaps, in the spirit of the ietf's openness, the wg might ask more widely and maybe a bit more formally. i.e. the wg might draft a message to be posted to the ieft list, and ask the secretariat to carry it to the other standards groups with which the ietf has liaison. it might tell of the requirements draft(s), explain their status, and solicit candidate protocols. along this line, if the drafts are ready to progress, we should move them through the process. the adelaide meeting means the iesg misses two telechats where we can progress documents. so we want this stuff on the agenda as soon as reasonably possible. randy From owner-aaa-bof@merit.edu Wed Mar 15 12:26:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA23297 for ; Wed, 15 Mar 2000 12:26:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A0705DE5F; Wed, 15 Mar 2000 12:24:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 204335DEBD; Wed, 15 Mar 2000 12:23:38 -0500 (EST) Received: from smtpgw1.sprintspectrum.com (smtpgw1.sprintspectrum.com [208.18.119.44]) by segue.merit.edu (Postfix) with ESMTP id 778165DEBF for ; Wed, 15 Mar 2000 12:20:48 -0500 (EST) Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id LAA00833; Wed, 15 Mar 2000 11:19:15 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 11:19:15 -0600 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC883A12CD@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'Randy Bush'" , Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion Date: Wed, 15 Mar 2000 11:19:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Randy, Are you stating that IETF does have formal Liaisons with other groups? I have recently been involved in a discussion between 3GPP2 and IESG regarding this. IESG indicated "we are not good at formal liaisons, so we don't do them". As far as asking for their input on proposed protocols, should they already be working in IETF to be doing this? I'm confused about how this would work. I believe that if these other groups do want to submit their own proposals they be allowed to do so, but on the IETF terms and timelines, not theirs. If they miss the window then that is their issue, not IETF's. My recommendation is that this WG not be concerned with other groups timelines or procedures, we do the work based on our timelines and procedures. If they cannot adapt then they miss the chance. This solves the issues of how to work within other groups timelines. It also meets the IETF criteria of being open and allowing anyone to submit their ideas. Now if I total missed the ideas here please disregard. Thanks Mark A. Lipford Manager, Wireless Industry Standards - Data Sprint PCS 8001 College Blvd.; Suite 210 Overland Park, KS 66210 (913) 664-8335 (office) (913) 664-8440 (fax) (913) 226-9060 (PCS) -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, March 15, 2000 9:59 AM To: Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion > Formally I don't think the IETF has any liaisons we do > However this kind of activity takes a good bit of effort and we can't > assume that the Secretariat will know what to do. i assure you that it is extremely safe assume it. > We also need to set timelines so we don't get held up with meeting > schedules of other fora. That can easily drag things out for months. again, you are wrapping yourself, and us with you, around perceived issues with other people's processes. instead of telling us what problems you think others will have, how about just doing a first draft of the solicitation? > Yes. I don't know what if anything is holding this process up now. imiho, talking about the wrong things. randy From owner-aaa-bof@merit.edu Wed Mar 15 12:56:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA23660 for ; Wed, 15 Mar 2000 12:56:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCD7F5DE1C; Wed, 15 Mar 2000 12:53:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B27175DE1F; Wed, 15 Mar 2000 12:53:43 -0500 (EST) Received: from keith.fenris.net (keith.fenris.net [158.222.0.2]) by segue.merit.edu (Postfix) with ESMTP id 13EE15DE1C for ; Wed, 15 Mar 2000 12:53:41 -0500 (EST) Received: from localhost (brian@localhost) by keith.fenris.net (8.9.3/8.9.3) with ESMTP id JAA05832; Wed, 15 Mar 2000 09:53:53 -0800 (PST) Date: Wed, 15 Mar 2000 09:53:53 -0800 (PST) From: Brian Lloyd X-Sender: brian@keith.fenris.net To: Matt Holdrege Cc: Randy Bush , aaa-wg@merit.edu Subject: RE: Re-charter discussion In-Reply-To: <4.2.2.20000315070845.00b4fb10@porky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, 15 Mar 2000, Matt Holdrege wrote: > At 07:05 AM 3/15/00 -0800, Randy Bush wrote: > > > This is where the problem is. We have already had over a year of > > discussion > > > about the candidate protocols and the requirements. True that discussion > > > has not occured in a formal WG, but it has happened. > > > >it also did not happen in the presence of agreed criteria. > > Well we have the criteria now (don't we?) so why can't we begin the debate? > Adelaide is the perfect place to start this as we can handle it face-2-face > to avoid misunderstandings. The primary communications medium for a working group is email. The discussion should be here. Not everybody who wishes to participate will be in Adelaide so ... Brian Lloyd brian@lloyd.com +1.530.676.6513 From owner-aaa-bof@merit.edu Wed Mar 15 13:55:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA24584 for ; Wed, 15 Mar 2000 13:55:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8306C5DDFC; Wed, 15 Mar 2000 13:55:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4FB695DDA5; Wed, 15 Mar 2000 13:55:06 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 58EED5DDFC for ; Wed, 15 Mar 2000 13:55:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17956; Wed, 15 Mar 2000 10:54:56 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA29863; Wed, 15 Mar 2000 10:54:56 -0800 (PST) Received: from darius (darius [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA23029; Wed, 15 Mar 2000 10:54:55 -0800 (PST) Message-Id: <200003151854.KAA23029@nasnfs.eng.sun.com> Date: Wed, 15 Mar 2000 10:54:55 -0800 (PST) From: Jonathan Wood Reply-To: Jonathan Wood Subject: RE: Re-charter discussion To: randy@psg.com Cc: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wje2CbpAZrUCU4OFZ8lFRw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_33 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk >>> what candidates are there? >> Good point. Can we ask (formally if necessary) the authors of any AAA >> protocol that thinks they meet the current requirements to stand up and >> raise their hand? > Pat Calhoun is on vacation and hence unavailable until Adelaide, so I'll raise a hand for him for DIAMETER. Note that a new set of DIAMETER IDs just appeared today; there have been some significant changes, so please make sure you get the latest versions if you wish to review them. Jon Wood SunLabs Networking and Security Center From owner-aaa-bof@merit.edu Thu Mar 16 02:44:22 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA05463 for ; Thu, 16 Mar 2000 02:44:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE6C75DD93; Thu, 16 Mar 2000 02:44:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A9B445DDAC; Thu, 16 Mar 2000 02:44:00 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id D46265DD93 for ; Thu, 16 Mar 2000 02:43:58 -0500 (EST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id XAA14749; Wed, 15 Mar 2000 23:37:28 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 16 Mar 2000 07:43:57 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id XAA00184; Wed, 15 Mar 2000 23:43:56 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000315233720.00b7c450@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 23:43:58 -0800 To: Randy Bush From: Matt Holdrege Subject: RE: Re-charter discussion Cc: aaa-wg@merit.edu In-Reply-To: References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> <4.2.2.20000315070845.00b4fb10@porky> <4.2.2.20000315073132.00b70ba0@porky> <4.2.2.20000315074322.00b67690@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:59 AM 3/15/00 -0800, Randy Bush wrote: > > Formally I don't think the IETF has any liaisons > >we do Maybe things have changed with the ITU? I know that we had to go through ISOC previously. And what about 3GPP or TIA? I'll bug Scott in Adelaide to be sure. > > However this kind of activity takes a good bit of effort and we can't > > assume that the Secretariat will know what to do. > >i assure you that it is extremely safe assume it. This puzzles me. How can the secretariat know which working groups of which international or regional standards fora is working on AAA? Even some of the WG's in question don't know at times. :) > > We also need to set timelines so we don't get held up with meeting > > schedules of other fora. That can easily drag things out for months. > >again, you are wrapping yourself, and us with you, around perceived issues >with other people's processes. instead of telling us what problems you >think others will have, how about just doing a first draft of the >solicitation? I'm just trying to help folks understand the issues. I don't believe it is an easy task. I roughly understand the other peoples processes since I'm one of them (i participate in many other fora). But it's fair to ask me to draft a solicitation (I did volunteer to help) and I'll give it a try. From owner-aaa-bof@merit.edu Thu Mar 16 07:07:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA09513 for ; Thu, 16 Mar 2000 07:07:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 914B45DE12; Thu, 16 Mar 2000 07:04:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6F0075DE11; Thu, 16 Mar 2000 07:04:49 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id E89985DE12 for ; Thu, 16 Mar 2000 07:02:56 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12VYzP-0002Xb-00; Thu, 16 Mar 2000 04:02:55 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: aaa-wg@merit.edu Subject: RE: Re-charter discussion References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> <4.2.2.20000315060422.00b5d220@porky> <4.2.2.20000315070845.00b4fb10@porky> <4.2.2.20000315073132.00b70ba0@porky> <4.2.2.20000315074322.00b67690@porky> <4.2.2.20000315233720.00b7c450@porky> Message-Id: Date: Thu, 16 Mar 2000 04:02:55 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk >>> Formally I don't think the IETF has any liaisons >> >>we do > > Maybe things have changed with the ITU? I know that we had to go through > ISOC previously. And what about 3GPP or TIA? I'll bug Scott in Adelaide to > be sure. > > >>> However this kind of activity takes a good bit of effort and we can't >>> assume that the Secretariat will know what to do. >> >>i assure you that it is extremely safe assume it. > > This puzzles me. How can the secretariat know which working groups of which > international or regional standards fora is working on AAA? Even some of > the WG's in question don't know at times. :) > >>> We also need to set timelines so we don't get held up with meeting >>> schedules of other fora. That can easily drag things out for months. >> >>again, you are wrapping yourself, and us with you, around perceived issues >>with other people's processes. instead of telling us what problems you >>think others will have, how about just doing a first draft of the >>solicitation? > > I'm just trying to help folks understand the issues. I don't believe it is > an easy task. I roughly understand the other peoples processes since I'm > one of them (i participate in many other fora). But it's fair to ask me to > draft a solicitation (I did volunteer to help) and I'll give it a try. could we please focus and make progress on what we need to do, as opposed to why we think others can't do what they're supposed to? the latter seems rather unproductive. randy From owner-aaa-bof@merit.edu Thu Mar 16 11:28:12 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13293 for ; Thu, 16 Mar 2000 11:28:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 018D55DDF7; Thu, 16 Mar 2000 11:26:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D76765DE0C; Thu, 16 Mar 2000 11:26:50 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 993A95DE0A for ; Thu, 16 Mar 2000 11:26:49 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA14897 for ; Thu, 16 Mar 2000 11:30:02 -0500 (EST) Received: from unknown(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma014805; Thu, 16 Mar 00 11:29:11 -0500 Received: from cabletron.com ([134.141.6.67]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id LAA02574; Thu, 16 Mar 2000 11:25:23 -0500 (EST) Message-ID: <38D10AD2.CD9B7FBE@cabletron.com> Date: Thu, 16 Mar 2000 11:24:50 -0500 From: David Harrington Organization: Enterasys X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: Re-charter discussion References: <2D11BCC7FFD8D3118FD70000D1ECDC883A12C6@pkcexv018.sprintspectrum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, I have a serious problem with the assumption that ONE protocol will meet all these criteria, and that if ONE protocol doesn't meet all criteria that we should design ONE protocol to meet all criteria. While we may have a stable requirements document, I don't think we are ready to select ONE candidate protocol. I don't have a protocol on the table, and don't plan to submit ONE for consideration. I think we might be better served by selecting a number of candidate protocols that already exist that are best suited to specific applications, and defining the glue to integrate them. This would allow us to take advantage of best-of-breed solutions that have been field-tested already. The method we are using of forcing any candidate to meet ALL the requirements doesn't permit the selection of a group of protocols that could be used together, with appropriate glue for standardization, to meet a set of specific needs. dbh "Lipford, Mark" wrote: > > I have been watching these last few exchanges go back and forth. > > I agree that we need a "formal" set of requirements before we can start the > discussion. > > Based on the response that I have seen (or not seen) on this list on the > requirements I-D I believe we have a very stable list of requirements and > recommend we DO start the discussion in Adelaide. I think it is a well > understood process that development in general will usually start on new > products (or protocols) prior to having a formalized requirements document. > I say we do the same thing. We have a very stable document that simply > needs to have an RFC number attached to it (I know there is more to it then > that), but the essence of the document will not be changed. > > Let's have the re-charter discussion in Adelaide and let's kick-off the > protocol debate. > > One of the responses on this thread indicated a need to start working on a > comparison document. Let's start that. As a user of the service I would be > happy to assist in providing a "users" thoughts on the protocols, but to > date I know of only one protocol out there sitting and waiting, if there are > others please make them known so we can get started. > > I also agree with Matt on a couple of points. > If there is agreement in Adelaide on a protocol let's get on with it and not > waste time. I too am frustrated at the time this is taking. I need a > protocol I can deploy now and RADIUS simply does not meet my needs. > > I have seen nor heard anything that specifically states we cannot get > started in Adelaide (or sooner by e-mail). > > Mark A. Lipford > Manager, Wireless Industry Standards - Data > Sprint PCS > 8001 College Blvd.; Suite 210 > Overland Park, KS 66210 > (913) 664-8335 (office) > (913) 664-8440 (fax) > (913) 226-9060 (PCS) > > -----Original Message----- > From: Matt Holdrege [mailto:holdrege@lucent.com] > Sent: Wednesday, March 15, 2000 9:33 AM > To: Randy Bush > Cc: aaa-wg@merit.edu > Subject: RE: Re-charter discussion > > At 07:26 AM 3/15/00 -0800, Randy Bush wrote: > >what candidates are there? > > Good point. Can we ask (formally if necessary) the authors of any AAA > protocol that thinks they meet the current requirements to stand up and > raise their hand? From owner-aaa-bof@merit.edu Thu Mar 16 11:51:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13710 for ; Thu, 16 Mar 2000 11:51:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id A614D5DE69; Thu, 16 Mar 2000 11:50:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 90F495DE89; Thu, 16 Mar 2000 11:50:35 -0500 (EST) Received: from malone.cisco.com (malone.cisco.com [171.68.225.99]) by segue.merit.edu (Postfix) with ESMTP id 5963D5DE69 for ; Thu, 16 Mar 2000 11:50:27 -0500 (EST) Received: from dkirsch.cisco.com ([171.70.221.22] (may be forged)) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA17832; Thu, 16 Mar 2000 08:48:47 -0800 (PST) Message-Id: <4.3.2.20000316114424.00b06a30@malone.cisco.com> X-Sender: dkirsch@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 16 Mar 2000 11:47:57 -0500 To: David Harrington , aaa-wg@merit.edu From: David Kirsch Subject: Re: Re-charter discussion In-Reply-To: <38D10AD2.CD9B7FBE@cabletron.com> References: <2D11BCC7FFD8D3118FD70000D1ECDC883A12C6@pkcexv018.sprintspectrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk I must agree with David on this...even in some of the requirements documents that are now written we have stated that there is not one protocol that covers all our requirements. I also believe that while there has been discussion as to protocols, primarily outside of formal discussion, that it would be appropriate to make a formal solicitation from the upcoming meeting to allow any other inputs to be evaluated as well. Would that not be appropriate? That also would allow for inputs from other working bodies while still having IETF AAA WG doing it's work itself and not cross - relying on others (as has been pointed out on this thread). Would such a path, including a formal call for submissions to be evaluated, be appropriate? Cheers, David K. At 11:24 AM 03/16/2000 -0500, David Harrington wrote: >Hi, > >I have a serious problem with the assumption that ONE protocol will meet >all these criteria, and that if ONE protocol doesn't meet all criteria >that we should design ONE protocol to meet all criteria. > >While we may have a stable requirements document, I don't think we are >ready to select ONE candidate protocol. I don't have a protocol on the >table, and don't plan to submit ONE for consideration. > >I think we might be better served by selecting a number of candidate >protocols that already exist that are best suited to specific >applications, and defining the glue to integrate them. This would allow >us to take advantage of best-of-breed solutions that have been >field-tested already. > >The method we are using of forcing any candidate to meet ALL the >requirements doesn't permit the selection of a group of protocols that >could be used together, with appropriate glue for standardization, to >meet a set of specific needs. > >dbh > >"Lipford, Mark" wrote: > > > > I have been watching these last few exchanges go back and forth. > > > > I agree that we need a "formal" set of requirements before we can start the > > discussion. > > > > Based on the response that I have seen (or not seen) on this list on the > > requirements I-D I believe we have a very stable list of requirements and > > recommend we DO start the discussion in Adelaide. I think it is a well > > understood process that development in general will usually start on new > > products (or protocols) prior to having a formalized requirements document. > > I say we do the same thing. We have a very stable document that simply > > needs to have an RFC number attached to it (I know there is more to it then > > that), but the essence of the document will not be changed. > > > > Let's have the re-charter discussion in Adelaide and let's kick-off the > > protocol debate. > > > > One of the responses on this thread indicated a need to start working on a > > comparison document. Let's start that. As a user of the service I > would be > > happy to assist in providing a "users" thoughts on the protocols, but to > > date I know of only one protocol out there sitting and waiting, if > there are > > others please make them known so we can get started. > > > > I also agree with Matt on a couple of points. > > If there is agreement in Adelaide on a protocol let's get on with it > and not > > waste time. I too am frustrated at the time this is taking. I need a > > protocol I can deploy now and RADIUS simply does not meet my needs. > > > > I have seen nor heard anything that specifically states we cannot get > > started in Adelaide (or sooner by e-mail). > > > > Mark A. Lipford > > Manager, Wireless Industry Standards - Data > > Sprint PCS > > 8001 College Blvd.; Suite 210 > > Overland Park, KS 66210 > > (913) 664-8335 (office) > > (913) 664-8440 (fax) > > (913) 226-9060 (PCS) > > > > -----Original Message----- > > From: Matt Holdrege [mailto:holdrege@lucent.com] > > Sent: Wednesday, March 15, 2000 9:33 AM > > To: Randy Bush > > Cc: aaa-wg@merit.edu > > Subject: RE: Re-charter discussion > > > > At 07:26 AM 3/15/00 -0800, Randy Bush wrote: > > >what candidates are there? > > > > Good point. Can we ask (formally if necessary) the authors of any AAA > > protocol that thinks they meet the current requirements to stand up and > > raise their hand? > ---------------------------------------------------------------------------- David Kirsch Cisco Systems, Inc. Consulting Engineering 13615 Dulles Technology Dr Office of the CTO Herndon, Virginia 20171 Desk #. 703.484.5761 Mobile #: 703.608.4927 CLLI: HRNDVADUDS0 ---------------------------------------------------------------------------- http://www.NetAid.Org "The power to end extreme poverty" From owner-aaa-bof@merit.edu Thu Mar 16 19:23:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA20112 for ; Thu, 16 Mar 2000 19:23:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA5455DD93; Thu, 16 Mar 2000 19:22:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C7AA85DD92; Thu, 16 Mar 2000 19:22:43 -0500 (EST) Received: from TYO203.gate.nec.co.jp (TYO203.gate.nec.co.jp [202.32.8.211]) by segue.merit.edu (Postfix) with ESMTP id A967B5DD8C for ; Thu, 16 Mar 2000 19:22:41 -0500 (EST) Received: from mailsv.nec.co.jp (mailsv-le1 [192.168.1.90]) by TYO203.gate.nec.co.jp (8.9.3/3.7W99122211) with ESMTP id JAA23162 for ; Fri, 17 Mar 2000 09:22:40 +0900 (JST) Received: from ssie1.ssi.sws.abk.nec.co.jp. (ssie1.ssi.sws.abk.nec.co.jp [10.41.168.51]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP id JAA00602 for ; Fri, 17 Mar 2000 09:22:39 +0900 (JST) Received: from ssie7.ssi.sws.abk.nec.co.jp (ssie7.ssi.sws.abk.nec.co.jp [10.41.168.57]) by ssie1.ssi.sws.abk.nec.co.jp. (8.9.3/3.7W-SSI-09/01/99) with ESMTP id JAA02459 for ; Fri, 17 Mar 2000 09:22:36 +0900 (JST) Received: from ssip21 (ssip21 [10.41.169.21]) by ssie7.ssi.sws.abk.nec.co.jp (8.8.8+2.7Wbeta7/CF3.3W9-SSS_C950609) with SMTP id JAA00801 for ; Fri, 17 Mar 2000 09:22:18 +0900 (JST) To: aaa-wg@merit.edu Subject: Re: Re-charter discussion In-reply-to: Your message of "Thu, 16 Mar 2000 11:24:50 -0500" <38D10AD2.CD9B7FBE@cabletron.com> References: <38D10AD2.CD9B7FBE@cabletron.com> From: "=?ISO-2022-JP?B?GyRCPi46ZDBvTGkbKEI=?= " Date: Fri, 17 Mar 2000 09:20:39 +0900 Message-Id: <20000317092039kosaka@ssie7.sws.abk.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: WeMail32[1.96] ID:ABKSWS Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi all. This is my first post. The problem seems to be the last part of the second paragraph where it says "...or whether it is necessary to design one from scratch." This part probably needs a modification so it doesn't tie us to ONE protocol. But other parts I think are simply saying : Lets select one protocol that covers more requirement features than others do, so we can start from the point that is the closest to our ultimate AAA protocol set. Itsuya Kosaka NEC Corp. >Hi, > >I have a serious problem with the assumption that ONE protocol will meet >all these criteria, and that if ONE protocol doesn't meet all criteria >that we should design ONE protocol to meet all criteria. > >While we may have a stable requirements document, I don't think we are >ready to select ONE candidate protocol. I don't have a protocol on the >table, and don't plan to submit ONE for consideration. > >I think we might be better served by selecting a number of candidate >protocols that already exist that are best suited to specific >applications, and defining the glue to integrate them. This would allow >us to take advantage of best-of-breed solutions that have been >field-tested already. > >The method we are using of forcing any candidate to meet ALL the >requirements doesn't permit the selection of a group of protocols that >could be used together, with appropriate glue for standardization, to >meet a set of specific needs. > >dbh > >"Lipford, Mark" wrote: >> >> I have been watching these last few exchanges go back and forth. >> >> I agree that we need a "formal" set of requirements before we can start the >> discussion. >> >> Based on the response that I have seen (or not seen) on this list on the >> requirements I-D I believe we have a very stable list of requirements and >> recommend we DO start the discussion in Adelaide. I think it is a well >> understood process that development in general will usually start on new >> products (or protocols) prior to having a formalized requirements document. >> I say we do the same thing. We have a very stable document that simply >> needs to have an RFC number attached to it (I know there is more to it then >> that), but the essence of the document will not be changed. >> >> Let's have the re-charter discussion in Adelaide and let's kick-off the >> protocol debate. >> >> One of the responses on this thread indicated a need to start working on a >> comparison document. Let's start that. As a user of the service I would be >> happy to assist in providing a "users" thoughts on the protocols, but to >> date I know of only one protocol out there sitting and waiting, if there are >> others please make them known so we can get started. >> >> I also agree with Matt on a couple of points. >> If there is agreement in Adelaide on a protocol let's get on with it and not >> waste time. I too am frustrated at the time this is taking. I need a >> protocol I can deploy now and RADIUS simply does not meet my needs. >> >> I have seen nor heard anything that specifically states we cannot get >> started in Adelaide (or sooner by e-mail). >> >> Mark A. Lipford >> Manager, Wireless Industry Standards - Data >> Sprint PCS >> 8001 College Blvd.; Suite 210 >> Overland Park, KS 66210 >> (913) 664-8335 (office) >> (913) 664-8440 (fax) >> (913) 226-9060 (PCS) >> >> -----Original Message----- >> From: Matt Holdrege [mailto:holdrege@lucent.com] >> Sent: Wednesday, March 15, 2000 9:33 AM >> To: Randy Bush >> Cc: aaa-wg@merit.edu >> Subject: RE: Re-charter discussion >> >> At 07:26 AM 3/15/00 -0800, Randy Bush wrote: >> >what candidates are there? >> >> Good point. Can we ask (formally if necessary) the authors of any AAA >> protocol that thinks they meet the current requirements to stand up and >> raise their hand? > From owner-aaa-bof@merit.edu Thu Mar 16 23:27:12 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA23613 for ; Thu, 16 Mar 2000 23:27:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1AA9E5DD90; Thu, 16 Mar 2000 23:26:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0795C5DD93; Thu, 16 Mar 2000 23:26:51 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id A481F5DD90 for ; Thu, 16 Mar 2000 23:26:50 -0500 (EST) Received: from nerf.yikes.com (IDENT:rdp@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id UAA58262; Thu, 16 Mar 2000 20:26:38 -0800 (PST) (envelope-from rdp@perlman.com) Date: Thu, 16 Mar 2000 20:26:38 -0800 (PST) From: Richard Perlman Reply-To: perl@lucent.com To: =?ISO-2022-JP?B?GyRCPi46ZDBvTGkbKEI=?= Cc: aaa-wg@merit.edu Subject: Re: Re-charter discussion In-Reply-To: <20000317092039kosaka@ssie7.sws.abk.nec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Sender: owner-aaa-bof@merit.edu Precedence: bulk I would then add... "... and that can be extended or modified to support those requirements it does not presently support." Richard On Fri, 17 Mar 2000, [ISO-2022-JP] $B>.:d0oLi(B wrote: > Lets select one protocol that covers more requirement > features than others do, so we can start from the point > that is the closest to our ultimate AAA protocol set. From owner-aaa-bof@merit.edu Fri Mar 17 09:24:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA02450 for ; Fri, 17 Mar 2000 09:24:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D66B5DD8C; Fri, 17 Mar 2000 09:23:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1E44B5DD93; Fri, 17 Mar 2000 09:23:39 -0500 (EST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by segue.merit.edu (Postfix) with ESMTP id C150E5DD8C for ; Fri, 17 Mar 2000 09:23:37 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id JAA24588 for ; Fri, 17 Mar 2000 09:16:53 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdCAAv1vdp_; Fri Mar 17 09:16:49 2000 Received: from [138.120.49.10] by kanata-mh1.ca.newbridge.com with ESMTP for aaa-wg@merit.edu; Fri, 17 Mar 2000 09:22:19 -0500 Received: (from smap@localhost) by affserver.ca.newbridge.com. (8.8.5/8.8.5) id JAA18787 for ; Fri, 17 Mar 2000 09:22:43 -0500 (EST) Received: from mail-router.bridgewatersys.com(192.168.150.1) by affserver via smap (V1.3) id sma018782; Fri Mar 17 09:22:18 2000 Received: from bridgewatersys.com by bridgewatersys.com (SMI-8.6/SMI-SVR4) id JAA25244; Fri, 17 Mar 2000 09:20:26 -0500 Message-Id: <38D241E6.93DA92B4@bridgewatersys.com> Date: Fri, 17 Mar 2000 09:32:06 -0500 From: Goutam Shaw Organization: Bridgewater Systems Corp. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: Re-charter discussion References: <2D11BCC7FFD8D3118FD70000D1ECDC883A12C6@pkcexv018.sprintspectrum.com> Content-Type: multipart/mixed; boundary="------------D2B5EC8CF90911B310E224E6" Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------D2B5EC8CF90911B310E224E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Lipford, Mark" wrote: > One of the responses on this thread indicated a need to start working on a > comparison document. Let's start that. As a user of the service I would be > happy to assist in providing a "users" thoughts on the protocols, but to > date I know of only one protocol out there sitting and waiting, if there are > others please make them known so we can get started. Could the following document be the starting point? draft-ekstein-nasreq-protcomp-01.txt I'm all for putting it on a fast track. ..Goutam. --------------D2B5EC8CF90911B310E224E6 Content-Type: text/x-vcard; charset=us-ascii; name="goutam.shaw.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Goutam Shaw Content-Disposition: attachment; filename="goutam.shaw.vcf" begin:vcard n:Shaw;Goutam x-mozilla-html:FALSE org:Bridgewater Systems Corp. adr:;;800-555 Legget Dr.;Ottawa;Ontario;K1G5J7;Canada version:2.1 email;internet:goutam.shaw@bridgewatersys.com title:Product Manager tel;fax:613-591-6656 tel;work:613-591-6655 x2796 x-mozilla-cpt:;0 fn:Goutam Shaw end:vcard --------------D2B5EC8CF90911B310E224E6-- From owner-aaa-bof@merit.edu Fri Mar 17 09:36:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA02696 for ; Fri, 17 Mar 2000 09:36:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F3EC5DD94; Fri, 17 Mar 2000 09:35:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F10735DD95; Fri, 17 Mar 2000 09:35:55 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id D53885DD94 for ; Fri, 17 Mar 2000 09:35:54 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA21373 for ; Fri, 17 Mar 2000 07:35:54 -0700 (MST)] Received: [from il93exb01.css.mot.com (il93exb01.css.mot.com [144.188.38.171]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA24975 for ; Fri, 17 Mar 2000 07:35:54 -0700 (MST)] Received: by il93exb01.css.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Mar 2000 08:35:55 -0600 Message-ID: <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com> From: Patzer Robert-RPATZER1 To: David Harrington , aaa-wg@merit.edu Subject: RE: Re-charter discussion Date: Fri, 17 Mar 2000 08:35:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk After attending the past AAA WG meetings and reading all the associated emails about this but remaining silent, I feel I must say something especially since I believe David has hit the nail on the head. We will NOT be able to "force-fit" any protocol (RADIUS, DIAMETER, COPS, OSP, etc.) to accomplish all the functions and features we are looking for: RADIUS DIAMETER COPS Authentication YES YES YES Authorization YES YES Client YES, User possible Accounting YES NO Not described Autoconfiguration YES YES YES Opaque Objects NO NO YES Attribute Tagging NO YES NO Vendor Specific NO YES NO Extensibility Unsolicited NO YES YES Messages Reliability YES, UDP YES, UDP NO, TCP Flow Control NO, UDP YES, UDP YES, TCP So it appears that to serve all of OUR best interests, we will either need to 1) find the "glue to integrate them" as David says below, or 2) do like the Japanese have with their cars which have just about blown the U.S. ones away and that is, to take the best aspects/functions of each of the existing protocols and assemble one protocol with all the best/needed characteristics (much more time consuming than option #1). Robert A. Patzer Motorola - PCS Stds. Admin. (847)523-5228 (800)SKYTEL2 PIN 1634493 Mobile (847) 721-3671 -----Original Message----- From: David Harrington [mailto:dbh@cabletron.com] Sent: Thursday, March 16, 2000 10:25 AM To: aaa-wg@merit.edu Subject: Re: Re-charter discussion Hi, I have a serious problem with the assumption that ONE protocol will meet all these criteria, and that if ONE protocol doesn't meet all criteria that we should design ONE protocol to meet all criteria. While we may have a stable requirements document, I don't think we are ready to select ONE candidate protocol. I don't have a protocol on the table, and don't plan to submit ONE for consideration. I think we might be better served by selecting a number of candidate protocols that already exist that are best suited to specific applications, and defining the glue to integrate them. This would allow us to take advantage of best-of-breed solutions that have been field-tested already. The method we are using of forcing any candidate to meet ALL the requirements doesn't permit the selection of a group of protocols that could be used together, with appropriate glue for standardization, to meet a set of specific needs. dbh "Lipford, Mark" wrote: > > I have been watching these last few exchanges go back and forth. > > I agree that we need a "formal" set of requirements before we can start the > discussion. > > Based on the response that I have seen (or not seen) on this list on the > requirements I-D I believe we have a very stable list of requirements and > recommend we DO start the discussion in Adelaide. I think it is a well > understood process that development in general will usually start on new > products (or protocols) prior to having a formalized requirements document. > I say we do the same thing. We have a very stable document that simply > needs to have an RFC number attached to it (I know there is more to it then > that), but the essence of the document will not be changed. > > Let's have the re-charter discussion in Adelaide and let's kick-off the > protocol debate. > > One of the responses on this thread indicated a need to start working on a > comparison document. Let's start that. As a user of the service I would be > happy to assist in providing a "users" thoughts on the protocols, but to > date I know of only one protocol out there sitting and waiting, if there are > others please make them known so we can get started. > > I also agree with Matt on a couple of points. > If there is agreement in Adelaide on a protocol let's get on with it and not > waste time. I too am frustrated at the time this is taking. I need a > protocol I can deploy now and RADIUS simply does not meet my needs. > > I have seen nor heard anything that specifically states we cannot get > started in Adelaide (or sooner by e-mail). > > Mark A. Lipford > Manager, Wireless Industry Standards - Data > Sprint PCS > 8001 College Blvd.; Suite 210 > Overland Park, KS 66210 > (913) 664-8335 (office) > (913) 664-8440 (fax) > (913) 226-9060 (PCS) > > -----Original Message----- > From: Matt Holdrege [mailto:holdrege@lucent.com] > Sent: Wednesday, March 15, 2000 9:33 AM > To: Randy Bush > Cc: aaa-wg@merit.edu > Subject: RE: Re-charter discussion > > At 07:26 AM 3/15/00 -0800, Randy Bush wrote: > >what candidates are there? > > Good point. Can we ask (formally if necessary) the authors of any AAA > protocol that thinks they meet the current requirements to stand up and > raise their hand? From owner-aaa-bof@merit.edu Fri Mar 17 10:22:47 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03589 for ; Fri, 17 Mar 2000 10:22:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 074555DD8C; Fri, 17 Mar 2000 10:22:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E90015DD93; Fri, 17 Mar 2000 10:22:27 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id C53565DD8C for ; Fri, 17 Mar 2000 10:22:26 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA11753 for ; Fri, 17 Mar 2000 08:22:26 -0700 (MST)] Received: [from il93exb02.css.mot.com (il93exb02.css.mot.com [144.188.38.172]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA05023 for ; Fri, 17 Mar 2000 08:22:26 -0700 (MST)] Received: by il93exb02.css.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Mar 2000 09:22:27 -0600 Message-ID: <1B429440C296D311A4C00008C7913F8D95168C@il93exm09.css.mot.com> From: Patzer Robert-RPATZER1 To: Goutam Shaw , aaa-wg@merit.edu Subject: RE: Re-charter discussion Date: Fri, 17 Mar 2000 09:22:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Goutam, after reading the below Draft, it seems pretty comprehensive so I agree it's a great starting point. I just wish we could meet in Adelaide Tues or Weds as I will not be able to make it Thurs or Fri but may have another Motorola person who can. Bob Robert A. Patzer Motorola - PCS Stds. Admin. (847)523-5228 (800)SKYTEL2 PIN 1634493 Mobile (847) 721-3671 -----Original Message----- From: Goutam Shaw [mailto:goutam.shaw@bridgewatersys.com] Sent: Friday, March 17, 2000 8:32 AM To: aaa-wg@merit.edu Subject: Re: Re-charter discussion "Lipford, Mark" wrote: > One of the responses on this thread indicated a need to start working on a > comparison document. Let's start that. As a user of the service I would be > happy to assist in providing a "users" thoughts on the protocols, but to > date I know of only one protocol out there sitting and waiting, if there are > others please make them known so we can get started. Could the following document be the starting point? draft-ekstein-nasreq-protcomp-01.txt I'm all for putting it on a fast track. ..Goutam. From owner-aaa-bof@merit.edu Fri Mar 17 10:36:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03810 for ; Fri, 17 Mar 2000 10:36:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9E4795DDA8; Fri, 17 Mar 2000 10:35:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8D2005DD95; Fri, 17 Mar 2000 10:35:52 -0500 (EST) Received: from merit.edu (stevie.merit.edu [198.108.62.185]) by segue.merit.edu (Postfix) with ESMTP id 6A1105DD93; Fri, 17 Mar 2000 10:35:51 -0500 (EST) Message-ID: <38D250D7.1ED2ED53@merit.edu> Date: Fri, 17 Mar 2000 10:35:51 -0500 From: John Vollbrecht Reply-To: jrv@merit.edu Organization: Merit Network Inc X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "pcalhoun@eng.sun.com" Cc: Tom =?iso-8859-1?Q?Weckstr=F6m?= , Richard Perlman , aaa-wg@merit.edu Subject: Re: Revised Network Access Requirements doc (Fwd) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I apologize for the lateness of the response, I am just now getting to some of these messages. I think the HOAS (or whatever) message is to tell the downstream server that a) the upstream server received the request b) it has not tossed it, but is still expecting to reply The requirement in a) might be alleviated if there were a reliable transport mechanism The requirement in b) needs to be supported still. For example, say a proxy receives a request but is unable to forward it because its path to the next hop is down.. What does it do then? Presumably the original sender might try to find a alternative path. If the sender has an algorithm to try an alternative, then it will activate this after a certain time unless it gets an HOAS message. The issue of failover in multihop sequences is complicated. The HOAS message would make it easier to implement a useful failover algorithm. John (HOAS is a great name for a message. I think we should do it just to include this in the spec :) ) "pcalhoun@eng.sun.com" wrote: > The 'hold on a sec' message (HOAS) was discussed some time back in the RADIUS > world. The reason why it was even desired in that space was that the protocol > provides no reliability whatsoever. A request is acknowledged when a response > is received, and if the request must traverse a set of proxies, it is > difficult to actually know whether the request was ever delivered. If the end > server had a slow database lookup, it would cause the NAS to retransmit the > request. > > In the AAA world, if each proxy in the network is responsible for ensuring > that the message made it to the next hop, via message acknowledgement, then > that node is responsible for re-routing the packet to an alternative hop if at > all possible. So, the HOAS would only make it to the next hop in the chain, > not all the way back to the NAS, IMHO, and the ONLY place that the HOAS > message would be generated, is at the home server, where a possibly slow > database lookup will occur. Note that the AAA protocol also assumes that there > is flow control, which will also eliminate one of the reasons why the HOAS was > desired in RADIUS, which could get 1000's of messages and wouldn't be able to > service them in a timely manner. > > So, the question is whether this feature is really needed. I'm not convinced > (but can be, given the proper argument). > > PatC > > > > > > > Richard, > > > > I might give in and agree... :) On the core network side (between NASes > > and AAA Servers) this kind of a negotiation might be a good thing. I was > > initially against a solution in which the end user, e.g. a Mobile Node, > > would have to go through painful message exchanges for different kind of > > parameters to set up the connection. > > From a Mobile IP end user point of view, the agent advertisements should > > contain enough information for the mobile to request a connection with > > specific parameters, and the next message for the Mobile would be a > > registration reply. > > BTW, single (or at least minimial number of) internet traversal is a > > requirement for a MIP + AAA registration, isn't it? > > > > Regards, > > Tom > > > > On Wed, 1 Mar 2000, Richard Perlman wrote: > > > > perl >Tom: > > perl > > > perl >I agree, such a "hold on a sec" features may be complicated to > > perl >implement. However, it is a real requirement for operators very wide > > area perl >(i.e. global) networks with complex roaming and exchange > > perl >relationships. With today's RADIUS implementations they must set a > > single perl >timeout on the NAS -- and they must choose the longest > > possible time. This perl >creates a less than optimal retry scenario for > > local AAA servers. perl > > > perl >Richard > > perl > > > perl >At 08:57 AM 02/28/2000 +0200, Tom K. Weckström wrote: > > perl >>I prefer the latter as well. > > perl >>As Richard noted, having a time limit in protocol requirements may not > > perl >>be a good idea. perl >> > > perl >>As a comment to Richard's idea of negotiating whether the required > > speed perl >>can be provided: I'd say that let's keep this simple. Having > > such perl >>negotiations would further complicate the state machine, the > > number of perl >>messages etc. The future AAA protocol will be complicated > > enough even perl >>without such elaborated negotiations. The simpler - the > > faster - the perl >>better. > > perl > > > > > -- > > Tom Weckström tweckstr@cc.hut.fi > > Helsinki University of Technology > > Department of Computer Science > > From owner-aaa-bof@merit.edu Fri Mar 17 10:51:30 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA04044 for ; Fri, 17 Mar 2000 10:51:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id C15E95DD93; Fri, 17 Mar 2000 10:51:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 913BD5DD95; Fri, 17 Mar 2000 10:51:08 -0500 (EST) Received: from frascone.com (adsl-216-62-83-25.dsl.rcsntx.swbell.net [216.62.83.25]) by segue.merit.edu (Postfix) with ESMTP id BEF545DD93 for ; Fri, 17 Mar 2000 10:51:06 -0500 (EST) Received: (from chaos@localhost) by frascone.com (8.9.3/8.9.3) id KAA10021; Fri, 17 Mar 2000 10:02:58 -0600 Date: Fri, 17 Mar 2000 10:02:57 -0600 From: David Frascone To: Patzer Robert-RPATZER1 Cc: David Harrington , aaa-wg@merit.edu Subject: Re: Re-charter discussion Message-ID: <20000317100257.A9932@newman.frascone.org> Reply-To: chaos@mindspring.com Mail-Followup-To: Patzer Robert-RPATZER1 , David Harrington , aaa-wg@merit.edu References: <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com>; from Robert_Patzer-RPATZER1@email.mot.com on Fri, Mar 17, 2000 at 08:35:51AM -0600 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk DIAMETER does have support for accounting. It looks like the only thing it is missing is Opaque objects. And, with the new draft, it is no longer going to be UDP, but SCTP (which still maintains reliability and flow control) Just my $.02 worth, Dave Frascone On Fri, Mar 17, 2000 at 08:35:51AM -0600, Patzer Robert-RPATZER1 wrote: > After attending the past AAA WG meetings and reading all the associated > emails about this but remaining silent, I feel I must say something > especially since I believe David has hit the nail on the head. We will NOT > be able to "force-fit" any protocol (RADIUS, DIAMETER, COPS, OSP, etc.) to > accomplish all the functions and features we are looking for: > RADIUS DIAMETER COPS > > Authentication YES YES YES > > Authorization YES YES Client YES, User > possible > > Accounting YES NO Not described > > Autoconfiguration YES YES YES > > Opaque Objects NO NO YES > > Attribute Tagging NO YES NO > > Vendor Specific NO YES NO > Extensibility > > Unsolicited NO YES YES > Messages > > Reliability YES, UDP YES, UDP NO, TCP > > Flow Control NO, UDP YES, UDP YES, TCP > > So it appears that to serve all of OUR best interests, we will either need > to 1) find the "glue to integrate them" as David says below, or 2) do like > the Japanese have with their cars which have just about blown the U.S. ones > away and that is, to take the best aspects/functions of each of the existing > protocols and assemble one protocol with all the best/needed > characteristics (much more time consuming than option #1). > Robert A. Patzer > Motorola - PCS > Stds. Admin. > (847)523-5228 > (800)SKYTEL2 PIN 1634493 > Mobile (847) 721-3671 > > -----Original Message----- > From: David Harrington [mailto:dbh@cabletron.com] > Sent: Thursday, March 16, 2000 10:25 AM > To: aaa-wg@merit.edu > Subject: Re: Re-charter discussion > > > Hi, > > I have a serious problem with the assumption that ONE protocol will meet > all these criteria, and that if ONE protocol doesn't meet all criteria > that we should design ONE protocol to meet all criteria. > > While we may have a stable requirements document, I don't think we are > ready to select ONE candidate protocol. I don't have a protocol on the > table, and don't plan to submit ONE for consideration. > > I think we might be better served by selecting a number of candidate > protocols that already exist that are best suited to specific > applications, and defining the glue to integrate them. This would allow > us to take advantage of best-of-breed solutions that have been > field-tested already. > > The method we are using of forcing any candidate to meet ALL the > requirements doesn't permit the selection of a group of protocols that > could be used together, with appropriate glue for standardization, to > meet a set of specific needs. > > dbh > > "Lipford, Mark" wrote: > > > > I have been watching these last few exchanges go back and forth. > > > > I agree that we need a "formal" set of requirements before we can start > the > > discussion. > > > > Based on the response that I have seen (or not seen) on this list on the > > requirements I-D I believe we have a very stable list of requirements and > > recommend we DO start the discussion in Adelaide. I think it is a well > > understood process that development in general will usually start on new > > products (or protocols) prior to having a formalized requirements > document. > > I say we do the same thing. We have a very stable document that simply > > needs to have an RFC number attached to it (I know there is more to it > then > > that), but the essence of the document will not be changed. > > > > Let's have the re-charter discussion in Adelaide and let's kick-off the > > protocol debate. > > > > One of the responses on this thread indicated a need to start working on a > > comparison document. Let's start that. As a user of the service I would > be > > happy to assist in providing a "users" thoughts on the protocols, but to > > date I know of only one protocol out there sitting and waiting, if there > are > > others please make them known so we can get started. > > > > I also agree with Matt on a couple of points. > > If there is agreement in Adelaide on a protocol let's get on with it and > not > > waste time. I too am frustrated at the time this is taking. I need a > > protocol I can deploy now and RADIUS simply does not meet my needs. > > > > I have seen nor heard anything that specifically states we cannot get > > started in Adelaide (or sooner by e-mail). > > > > Mark A. Lipford > > Manager, Wireless Industry Standards - Data > > Sprint PCS > > 8001 College Blvd.; Suite 210 > > Overland Park, KS 66210 > > (913) 664-8335 (office) > > (913) 664-8440 (fax) > > (913) 226-9060 (PCS) > > > > -----Original Message----- > > From: Matt Holdrege [mailto:holdrege@lucent.com] > > Sent: Wednesday, March 15, 2000 9:33 AM > > To: Randy Bush > > Cc: aaa-wg@merit.edu > > Subject: RE: Re-charter discussion > > > > At 07:26 AM 3/15/00 -0800, Randy Bush wrote: > > >what candidates are there? > > > > Good point. Can we ask (formally if necessary) the authors of any AAA > > protocol that thinks they meet the current requirements to stand up and > > raise their hand? From owner-aaa-bof@merit.edu Fri Mar 17 11:01:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA04197 for ; Fri, 17 Mar 2000 11:01:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 34C025DE01; Fri, 17 Mar 2000 11:00:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0921F5DE0D; Fri, 17 Mar 2000 11:00:26 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 612815DE09 for ; Fri, 17 Mar 2000 11:00:21 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Vz82-0009Qg-00; Fri, 17 Mar 2000 07:57:34 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: Re-charter discussion References: <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com> <20000317100257.A9932@newman.frascone.org> Message-Id: Date: Fri, 17 Mar 2000 07:57:34 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk indeed, i believe folk look on draft-ekstein-nasreq-protcomp-01.txt as a base. so discussion of it becomes rather relevant. but does it express well the needs of all the applications discussed in the aaa requirements? > DIAMETER does have support for accounting. given the wobbly record/use of radius in this area, it will be worth some digging to ensure we make the skeptics happy here, well, at least meet their objections . randy From owner-aaa-bof@merit.edu Fri Mar 17 11:28:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA04887 for ; Fri, 17 Mar 2000 11:28:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0804A5DD95; Fri, 17 Mar 2000 11:28:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E391F5DDFE; Fri, 17 Mar 2000 11:28:17 -0500 (EST) Received: from monitor.internaut.com (mg-206191146-3.ricochet.net [206.191.146.3]) by segue.merit.edu (Postfix) with ESMTP id 3501C5DD95 for ; Fri, 17 Mar 2000 11:28:12 -0500 (EST) Received: from vaiobean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id IAA90195; Fri, 17 Mar 2000 08:16:45 -0800 (PST) Reply-To: From: "Bernard Aboba" To: "'Randy Bush'" , "'Matt Holdrege'" Cc: Subject: RE: Re-charter discussion Date: Fri, 17 Mar 2000 08:27:51 -0800 Message-ID: <004601bf902d$be619ee0$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >perhaps, in the spirit of the ietf's openness, the wg might ask more widely >and maybe a bit more formally. i.e. the wg might draft a message to be >posted to the ieft list, and ask the secretariat to carry it to the other >standards groups with which the ietf has liaison. it might tell of the >requirements draft(s), explain their status, and solicit candidate >protocols. This is a great idea. I'll work on coming up with a draft announcement. >along this line, if the drafts are ready to progress, we should move them >through the process. WG last call will expire soon on the network requirements draft. So if the WG wants to comment on it they should do so NOW. The accounting drafts have been revv'd since WG last call (mostly for spelling and editorial changes) so they may need to go through WG last call again. But a goal of getting them all out the door seems very reachable at this point. From owner-aaa-bof@merit.edu Fri Mar 17 17:22:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10544 for ; Fri, 17 Mar 2000 17:22:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 43BCF5DD90; Fri, 17 Mar 2000 17:22:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 27B075DDA8; Fri, 17 Mar 2000 17:22:19 -0500 (EST) Received: from monitor.internaut.com (mg-206191146-3.ricochet.net [206.191.146.3]) by segue.merit.edu (Postfix) with ESMTP id 0E5295DD90 for ; Fri, 17 Mar 2000 17:22:06 -0500 (EST) Received: from vaiobean ([204.57.137.38]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id OAA90508 for ; Fri, 17 Mar 2000 14:11:01 -0800 (PST) Reply-To: From: "Bernard Aboba" To: Subject: AAA WG Last Call on draft-ietf-aaa-accounting-attributes-02.txt Date: Fri, 17 Mar 2000 14:22:08 -0800 Message-ID: <00dd01bf905f$3c8fe7a0$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <013f01bf83a0$a5a08630$428939cc@ntdev.microsoft.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk This is the AAA Working Group last call on draft-ietf-aaa-accounting-attributes-02.txt before sending it on to IETF Last Call. This draft is recommended for Informational status. If you have comments on it, please send them to the authors or to the aaa-wg@merit.edu mailing list BEFORE April 2. http://www.ietf.org/internet-drafts/draft-ietf-aaa-accounting-attributes-02. txt From owner-aaa-bof@merit.edu Sun Mar 19 12:03:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10484 for ; Sun, 19 Mar 2000 12:03:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D29B5DDAB; Sun, 19 Mar 2000 12:00:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F3C725DD9C; Sun, 19 Mar 2000 12:00:22 -0500 (EST) Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by segue.merit.edu (Postfix) with ESMTP id 230355DD8D for ; Sun, 19 Mar 2000 12:00:21 -0500 (EST) Received: from gamma.hut.fi (tweckstr@gamma.hut.fi [130.233.224.52]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA15526; Sun, 19 Mar 2000 18:59:54 +0200 (EET) Date: Sun, 19 Mar 2000 18:59:53 +0200 (EET) From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= To: Brian Lloyd Cc: Matt Holdrege , Randy Bush , aaa-wg@merit.edu Subject: RE: Re-charter discussion In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, 15 Mar 2000, Brian Lloyd wrote: brian >> Well we have the criteria now (don't we?) so why can't we begin the debate? brian >> Adelaide is the perfect place to start this as we can handle it face-2-face brian >> to avoid misunderstandings. brian > brian >The primary communications medium for a working group is email. The brian >discussion should be here. Not everybody who wishes to participate will brian >be in Adelaide so ... brian > brian >Brian Lloyd brian >brian@lloyd.com brian >+1.530.676.6513 I could not agree more. Please start up the discussion here on the mailing list before Adelaide. Let everybody know your ideas and opinions you are about to present in Adelaide regarding this issue. Knowing the 'discussion items and proposalös' before Adelaide would let us not attending the meeting send you our comments before the meeting. Needless to say, delivering the meeting notes quickly after the meeting is quite important as well to speed up the process... Regards, Tom -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Sun Mar 19 12:44:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10791 for ; Sun, 19 Mar 2000 12:44:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D0345DDAE; Sun, 19 Mar 2000 12:43:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E81235DDAD; Sun, 19 Mar 2000 12:43:39 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id B43945DD8D for ; Sun, 19 Mar 2000 12:43:38 -0500 (EST) Received: from pcrperlman (IDENT:root@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id JAA85414; Sun, 19 Mar 2000 09:43:26 -0800 (PST) (envelope-from perl@lucent.com) Message-Id: <4.2.2.20000319144237.00a9f420@mail.yikes.com> X-Sender: rdp@mail.yikes.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 19 Mar 2000 14:43:22 -0400 To: Tom =?iso-8859-1?Q?Weckstr=F6m?= , Brian Lloyd From: Richard Perlman Subject: RE: Re-charter discussion Cc: Matt Holdrege , Randy Bush , aaa-wg@merit.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA10791 Yes. another agreement. Let's start this now. Richard At 06:59 PM 03/19/2000 +0200, Tom Weckström wrote: >On Wed, 15 Mar 2000, Brian Lloyd wrote: > >brian >> Well we have the criteria now (don't we?) so why can't we begin >the debate? >brian >> Adelaide is the perfect place to start this as we can handle it >face-2-face >brian >> to avoid misunderstandings. >brian > >brian >The primary communications medium for a working group is email. The >brian >discussion should be here. Not everybody who wishes to participate >will >brian >be in Adelaide so ... >brian > >brian >Brian Lloyd >brian >brian@lloyd.com >brian >+1.530.676.6513 > >I could not agree more. Please start up the discussion here on the mailing >list before Adelaide. Let everybody know your ideas and opinions you are >about to present in Adelaide regarding this issue. Knowing the 'discussion >items and proposalös' before Adelaide would let us not attending the >meeting send you our comments before the meeting. >Needless to say, delivering the meeting notes quickly after the meeting is >quite important as well to speed up the process... > >Regards, > Tom > >-- > Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Mon Mar 20 08:27:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA24578 for ; Mon, 20 Mar 2000 08:27:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3B665DDB2; Mon, 20 Mar 2000 08:27:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B3E955DDB7; Mon, 20 Mar 2000 08:27:24 -0500 (EST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by segue.merit.edu (Postfix) with ESMTP id E8B8F5DDB2 for ; Mon, 20 Mar 2000 08:27:22 -0500 (EST) Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id OAA20880; Mon, 20 Mar 2000 14:26:42 +0100 (MET) Received: from alcatel.be (bt00q5 [138.203.66.115]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id OAA26528; Mon, 20 Mar 2000 14:26:33 +0100 (MET) Message-ID: <38D626FD.B77D59A9@alcatel.be> Date: Mon, 20 Mar 2000 14:26:22 +0100 From: Ronnie Ekstein X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush Cc: David Frascone , aaa-wg@merit.edu, "Yves T'joens" , BERNARD SALES , Olivier Paridaens Subject: Re: Re-charter discussion References: <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com> <20000317100257.A9932@newman.frascone.org> Content-Type: text/plain; charset=x-user-defined Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id IAA24578 Hello, Just note that we'll be present in Adelaide and that we will be pleased to further work on, discuss and expand draft-ekstein-nasreq-protcomp-01.txt. Kind regards, Ronnie Ekstein Yves T'Joens Bernard Sales Olivier Paridaens Randy Bush wrote: > indeed, i believe folk look on draft-ekstein-nasreq-protcomp-01.txt as a > base.  so discussion of it becomes rather relevant.  but does it express > well the needs of all the applications discussed in the aaa requirements? > > > DIAMETER does have support for accounting. > > given the wobbly record/use of radius in this area, it will be worth some > digging to ensure we make the skeptics happy here, well, at least meet their > objections . > > randy From owner-aaa-bof@merit.edu Mon Mar 20 18:18:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA04365 for ; Mon, 20 Mar 2000 18:18:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 141F35DDC6; Mon, 20 Mar 2000 18:17:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EBA315DDC5; Mon, 20 Mar 2000 18:17:35 -0500 (EST) Received: from keith.fenris.net (keith.fenris.net [158.222.0.2]) by segue.merit.edu (Postfix) with ESMTP id 7C2655DDC4 for ; Mon, 20 Mar 2000 18:17:34 -0500 (EST) Received: from murray (keith.fenris.net [158.222.0.2]) by keith.fenris.net (8.9.3/8.9.3) with SMTP id PAA22419 for ; Mon, 20 Mar 2000 15:18:03 -0800 (PST) Message-Id: <3.0.6.32.20000320151700.009244b0@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 20 Mar 2000 15:17:00 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Re: Re-charter discussion In-Reply-To: <20000317100257.A9932@newman.frascone.org> References: <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com> <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 10:02 AM 3/17/00 -0600, David Frascone wrote: >[DIAMETER] >And, with the new draft, it is no longer going to be UDP, but SCTP (which >still maintains reliability and flow control) How well is SCTP supported in various operating systems? Right now the only two transports I have access to in Java are TCP and UDP. If there isn't support for the required transport in the readily available languages, it will be difficult to roll implementations of Diameter. Brian Lloyd Lucent Technologies brian@lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax From owner-aaa-bof@merit.edu Wed Mar 22 14:15:06 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10802 for ; Wed, 22 Mar 2000 14:15:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B7AB5DDC5; Tue, 21 Mar 2000 05:23:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 122D65DDC7; Tue, 21 Mar 2000 05:23:06 -0500 (EST) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id 645905DDC5 for ; Tue, 21 Mar 2000 05:23:04 -0500 (EST) Received: from cc.hut.fi (root@gamma.hut.fi [130.233.224.52]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id MAA43666; Tue, 21 Mar 2000 12:22:35 +0200 (EET) Message-ID: <38D74D6B.9952A43D@cc.hut.fi> Date: Tue, 21 Mar 2000 12:22:35 +0200 From: Tom =?iso-8859-1?Q?Weckstr=F6m?= Organization: HUT/TKK X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686) X-Accept-Language: fi,sv,de MIME-Version: 1.0 To: Patzer Robert-RPATZER1 Cc: David Harrington , aaa-wg@merit.edu Subject: Re: Re-charter discussion References: <1B429440C296D311A4C00008C7913F8D9515ED@il93exm09.css.mot.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello, Excuse me my ignorance about some of the below mentioned protocols, but I'm conserned if anyone of those supports micropayments as part of the accounting process. Using micropayments might be a very handy approach for fast and scalable billing. Of course there is lots of else included in Accounting, like the resource consumption monitoring, etc. but a flexible billing/charging/payment method is a must anyway. I'd like you to raise the discussion on micropayments as one possible solution also in Adelaide, when discussing about the AAA protocol future. Regards, Tom Patzer Robert-RPATZER1 wrote: > > After attending the past AAA WG meetings and reading all the associated > emails about this but remaining silent, I feel I must say something > especially since I believe David has hit the nail on the head. We will NOT > be able to "force-fit" any protocol (RADIUS, DIAMETER, COPS, OSP, etc.) to > accomplish all the functions and features we are looking for: > RADIUS DIAMETER COPS > > Authentication YES YES YES > > Authorization YES YES Client YES, User > possible > > Accounting YES NO Not described > > Autoconfiguration YES YES YES > > Opaque Objects NO NO YES > > Attribute Tagging NO YES NO > > Vendor Specific NO YES NO > Extensibility > > Unsolicited NO YES YES > Messages > > Reliability YES, UDP YES, UDP NO, TCP > > Flow Control NO, UDP YES, UDP YES, TCP > > So it appears that to serve all of OUR best interests, we will either need > to 1) find the "glue to integrate them" as David says below, or 2) do like > the Japanese have with their cars which have just about blown the U.S. ones > away and that is, to take the best aspects/functions of each of the existing > protocols and assemble one protocol with all the best/needed > characteristics (much more time consuming than option #1). > Robert A. Patzer > Motorola - PCS > Stds. Admin. > (847)523-5228 > (800)SKYTEL2 PIN 1634493 > Mobile (847) 721-3671 > -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Sun Mar 26 23:12:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA07791 for ; Sun, 26 Mar 2000 23:12:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C4935DDB3; Sun, 26 Mar 2000 23:11:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EF93B5DDC0; Sun, 26 Mar 2000 23:11:46 -0500 (EST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id B335C5DDB3 for ; Sun, 26 Mar 2000 23:11:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26361; Sun, 26 Mar 2000 21:04:39 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA16492; Sun, 26 Mar 2000 20:04:39 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id UAA05077; Sun, 26 Mar 2000 20:04:23 -0800 (PST) From: Patrice Calhoun Message-Id: <200003270404.UAA05077@nasnfs.eng.sun.com> Date: Mon, 27 Mar 2000 14:29:58 -0800 To: "Mark Jones" , Reply-To: Subject: RE: Re-charter discussion X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk well, sphere would be pretty cool! It adds a third dimention. PatC >Well said, Matt. > >The need for a decision on the AAA base protocol is urgent for more than one >IETF (and non-IETF) WG. Waiting another six months increases the chance that >these different groups will be compelled to give up on the AAA WG and make >their own potentially different decisions. > >Looking through the AAA/NASREQ/MobileIP/ROAMOPS WG, I see drafts documenting >the requirements, the candidates and their relative merits. Can these drafts >be used as the basis for selecting a protocol in Adelaide? > >Even if the general consensus is to build a new protocol from scratch, an >interim AAA base protocol is still needed. RADIUS is over-stretched already. > >BTW, if a new protocol is the chosen route, please don't even think of >calling it CIRCUMFERENCE ;-) > >Regards, > Mark > > From owner-aaa-bof@merit.edu Sun Mar 26 23:49:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA08180 for ; Sun, 26 Mar 2000 23:49:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 901CA5DD8F; Sun, 26 Mar 2000 23:49:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 73A135DDC0; Sun, 26 Mar 2000 23:49:09 -0500 (EST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 4369F5DD8F for ; Sun, 26 Mar 2000 23:49:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA08576; Sun, 26 Mar 2000 21:49:05 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA29316; Sun, 26 Mar 2000 20:49:03 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id UAA05756; Sun, 26 Mar 2000 20:48:44 -0800 (PST) From: Patrice Calhoun Message-Id: <200003270448.UAA05756@nasnfs.eng.sun.com> Date: Mon, 27 Mar 2000 15:14:24 -0800 To: "David Kirsch" , , "David Harrington" Reply-To: Subject: Re: Re-charter discussion X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk >I must agree with David on this...even in some of the requirements >documents that are now written we have stated that there is not one >protocol that covers all our requirements. > >I also believe that while there has been discussion as to protocols, >primarily outside of formal discussion, that it would be appropriate to >make a formal solicitation from the upcoming meeting to allow any other >inputs to be evaluated as well. Would that not be appropriate? That also >would allow for inputs from other working bodies while still having IETF >AAA WG doing it's work itself and not cross - relying on others (as has >been pointed out on this thread). And where was this stated? I happen to know of one that does, in fact, as far as I can tell, satisfy all requirements. I am not stating that only one should be selected, but I don't see the need to specifically choose multiple protocols if a single one could do the job. > >Would such a path, including a formal call for submissions to be evaluated, >be appropriate? How formal should this be? The requirements are in, if you have a protocol please speak up. The reality is, no one will personally mail a giftbox to all IETF engineers requesting protocol submission. Someone in this thread already asked for people to put up their hands, that was good enough for me. Once we know what all of the candidates are, we can then start documenting whether they do, or don't, meet the requirements. PatC PatC > >Cheers, > >David K. > >At 11:24 AM 03/16/2000 -0500, David Harrington wrote: >>Hi, >> >>I have a serious problem with the assumption that ONE protocol will meet >>all these criteria, and that if ONE protocol doesn't meet all criteria >>that we should design ONE protocol to meet all criteria. >> >>While we may have a stable requirements document, I don't think we are >>ready to select ONE candidate protocol. I don't have a protocol on the >>table, and don't plan to submit ONE for consideration. >> >>I think we might be better served by selecting a number of candidate >>protocols that already exist that are best suited to specific >>applications, and defining the glue to integrate them. This would allow >>us to take advantage of best-of-breed solutions that have been >>field-tested already. >> >>The method we are using of forcing any candidate to meet ALL the >>requirements doesn't permit the selection of a group of protocols that >>could be used together, with appropriate glue for standardization, to >>meet a set of specific needs. >> >>dbh >> >>"Lipford, Mark" wrote: >> > >> > I have been watching these last few exchanges go back and forth. >> > >> > I agree that we need a "formal" set of requirements before we can start the >> > discussion. >> > >> > Based on the response that I have seen (or not seen) on this list on the >> > requirements I-D I believe we have a very stable list of requirements and >> > recommend we DO start the discussion in Adelaide. I think it is a well >> > understood process that development in general will usually start on new >> > products (or protocols) prior to having a formalized requirements document. >> > I say we do the same thing. We have a very stable document that simply >> > needs to have an RFC number attached to it (I know there is more to it then >> > that), but the essence of the document will not be changed. >> > >> > Let's have the re-charter discussion in Adelaide and let's kick-off the >> > protocol debate. >> > >> > One of the responses on this thread indicated a need to start working on a >> > comparison document. Let's start that. As a user of the service I >> would be >> > happy to assist in providing a "users" thoughts on the protocols, but to >> > date I know of only one protocol out there sitting and waiting, if >> there are >> > others please make them known so we can get started. >> > >> > I also agree with Matt on a couple of points. >> > If there is agreement in Adelaide on a protocol let's get on with it >> and not >> > waste time. I too am frustrated at the time this is taking. I need a >> > protocol I can deploy now and RADIUS simply does not meet my needs. >> > >> > I have seen nor heard anything that specifically states we cannot get >> > started in Adelaide (or sooner by e-mail). >> > >> > Mark A. Lipford >> > Manager, Wireless Industry Standards - Data >> > Sprint PCS >> > 8001 College Blvd.; Suite 210 >> > Overland Park, KS 66210 >> > (913) 664-8335 (office) >> > (913) 664-8440 (fax) >> > (913) 226-9060 (PCS) >> > >> > -----Original Message----- >> > From: Matt Holdrege [mailto:holdrege@lucent.com] >> > Sent: Wednesday, March 15, 2000 9:33 AM >> > To: Randy Bush >> > Cc: aaa-wg@merit.edu >> > Subject: RE: Re-charter discussion >> > >> > At 07:26 AM 3/15/00 -0800, Randy Bush wrote: >> > >what candidates are there? >> > >> > Good point. Can we ask (formally if necessary) the authors of any AAA >> > protocol that thinks they meet the current requirements to stand up and >> > raise their hand? >> > >---------------------------------------------------------------------------- >David Kirsch Cisco Systems, Inc. >Consulting Engineering 13615 Dulles Technology Dr >Office of the CTO Herndon, Virginia 20171 >Desk #. 703.484.5761 Mobile #: 703.608.4927 >CLLI: HRNDVADUDS0 >---------------------------------------------------------------------------- >http://www.NetAid.Org >"The power to end extreme poverty" > > From owner-aaa-bof@merit.edu Sun Mar 26 23:58:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA08274 for ; Sun, 26 Mar 2000 23:58:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A2F55DDD2; Sun, 26 Mar 2000 23:58:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 370D65DDD0; Sun, 26 Mar 2000 23:58:28 -0500 (EST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 052775DDC0 for ; Sun, 26 Mar 2000 23:58:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11613; Sun, 26 Mar 2000 21:58:25 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA29635; Sun, 26 Mar 2000 20:58:23 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id UAA05903; Sun, 26 Mar 2000 20:58:01 -0800 (PST) From: Patrice Calhoun Message-Id: <200003270458.UAA05903@nasnfs.eng.sun.com> Date: Mon, 27 Mar 2000 15:23:44 -0800 To: "Patzer Robert-RPATZER1" , , "David Harrington" Reply-To: Subject: RE: Re-charter discussion X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I believe that you have missed a pretty important DIAMETER Internet Draft, appropriately named, DIAMETER Accounting Extension. So, I would ask that you change your table below to include YES for accounting under DIAMETER. The latest DIAMETER base protocol relies on SCTP, not UDP. PatC >After attending the past AAA WG meetings and reading all the associated >emails about this but remaining silent, I feel I must say something >especially since I believe David has hit the nail on the head. We will NOT >be able to "force-fit" any protocol (RADIUS, DIAMETER, COPS, OSP, etc.) to >accomplish all the functions and features we are looking for: > RADIUS DIAMETER COPS > >Authentication YES YES YES > >Authorization YES YES Client YES, User >possible > >Accounting YES NO Not described > >Autoconfiguration YES YES YES > >Opaque Objects NO NO YES > >Attribute Tagging NO YES NO > >Vendor Specific NO YES NO >Extensibility > >Unsolicited NO YES YES >Messages > >Reliability YES, UDP YES, UDP NO, TCP > >Flow Control NO, UDP YES, UDP YES, TCP > >So it appears that to serve all of OUR best interests, we will either need >to 1) find the "glue to integrate them" as David says below, or 2) do like >the Japanese have with their cars which have just about blown the U.S. ones >away and that is, to take the best aspects/functions of each of the existing >protocols and assemble one protocol with all the best/needed >characteristics (much more time consuming than option #1). >Robert A. Patzer >Motorola - PCS >Stds. Admin. >(847)523-5228 >(800)SKYTEL2 PIN 1634493 >Mobile (847) 721-3671 > >-----Original Message----- >From: David Harrington [mailto:dbh@cabletron.com] >Sent: Thursday, March 16, 2000 10:25 AM >To: aaa-wg@merit.edu >Subject: Re: Re-charter discussion > > >Hi, > >I have a serious problem with the assumption that ONE protocol will meet >all these criteria, and that if ONE protocol doesn't meet all criteria >that we should design ONE protocol to meet all criteria. > >While we may have a stable requirements document, I don't think we are >ready to select ONE candidate protocol. I don't have a protocol on the >table, and don't plan to submit ONE for consideration. > >I think we might be better served by selecting a number of candidate >protocols that already exist that are best suited to specific >applications, and defining the glue to integrate them. This would allow >us to take advantage of best-of-breed solutions that have been >field-tested already. > >The method we are using of forcing any candidate to meet ALL the >requirements doesn't permit the selection of a group of protocols that >could be used together, with appropriate glue for standardization, to >meet a set of specific needs. > >dbh > >"Lipford, Mark" wrote: >> >> I have been watching these last few exchanges go back and forth. >> >> I agree that we need a "formal" set of requirements before we can start >the >> discussion. >> >> Based on the response that I have seen (or not seen) on this list on the >> requirements I-D I believe we have a very stable list of requirements and >> recommend we DO start the discussion in Adelaide. I think it is a well >> understood process that development in general will usually start on new >> products (or protocols) prior to having a formalized requirements >document. >> I say we do the same thing. We have a very stable document that simply >> needs to have an RFC number attached to it (I know there is more to it >then >> that), but the essence of the document will not be changed. >> >> Let's have the re-charter discussion in Adelaide and let's kick-off the >> protocol debate. >> >> One of the responses on this thread indicated a need to start working on a >> comparison document. Let's start that. As a user of the service I would >be >> happy to assist in providing a "users" thoughts on the protocols, but to >> date I know of only one protocol out there sitting and waiting, if there >are >> others please make them known so we can get started. >> >> I also agree with Matt on a couple of points. >> If there is agreement in Adelaide on a protocol let's get on with it and >not >> waste time. I too am frustrated at the time this is taking. I need a >> protocol I can deploy now and RADIUS simply does not meet my needs. >> >> I have seen nor heard anything that specifically states we cannot get >> started in Adelaide (or sooner by e-mail). >> >> Mark A. Lipford >> Manager, Wireless Industry Standards - Data >> Sprint PCS >> 8001 College Blvd.; Suite 210 >> Overland Park, KS 66210 >> (913) 664-8335 (office) >> (913) 664-8440 (fax) >> (913) 226-9060 (PCS) >> >> -----Original Message----- >> From: Matt Holdrege [mailto:holdrege@lucent.com] >> Sent: Wednesday, March 15, 2000 9:33 AM >> To: Randy Bush >> Cc: aaa-wg@merit.edu >> Subject: RE: Re-charter discussion >> >> At 07:26 AM 3/15/00 -0800, Randy Bush wrote: >> >what candidates are there? >> >> Good point. Can we ask (formally if necessary) the authors of any AAA >> protocol that thinks they meet the current requirements to stand up and >> raise their hand? > From owner-aaa-bof@merit.edu Mon Mar 27 00:13:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA08439 for ; Mon, 27 Mar 2000 00:13:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07DF15DDC0; Mon, 27 Mar 2000 00:12:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAB255DDD0; Mon, 27 Mar 2000 00:12:47 -0500 (EST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id BDEBD5DDC0 for ; Mon, 27 Mar 2000 00:12:46 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15573; Sun, 26 Mar 2000 22:12:44 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA00101; Sun, 26 Mar 2000 21:12:42 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id VAA06120; Sun, 26 Mar 2000 21:12:28 -0800 (PST) From: Patrice Calhoun Message-Id: <200003270512.VAA06120@nasnfs.eng.sun.com> Date: Mon, 27 Mar 2000 15:38:04 -0800 To: "Brian Lloyd" , Reply-To: Subject: Re: Re-charter discussion X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Certain people that REALLY care about transports really didn't want to see yet another reliable protocol that needed to be reviewed, etc. This was at the request of such people. If the WG decides that we need to move away from SCTP, and do our own, I would like to make sure that the IESG is in agreement. PatC >At 10:02 AM 3/17/00 -0600, David Frascone wrote: >>[DIAMETER] >>And, with the new draft, it is no longer going to be UDP, but SCTP (which >>still maintains reliability and flow control) > >How well is SCTP supported in various operating systems? Right now the >only two transports I have access to in Java are TCP and UDP. If there >isn't support for the required transport in the readily available >languages, it will be difficult to roll implementations of Diameter. > > >Brian Lloyd Lucent Technologies >brian@lloyd.com 3461 Robin Lane, Suite 1 >http://www.livingston.com Cameron Park, CA 95682 >+1.530.676.6513 - voice +1.530.676.3442 - fax > > From owner-aaa-bof@merit.edu Mon Mar 27 12:54:20 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA04659 for ; Mon, 27 Mar 2000 12:54:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id D44115DD9F; Mon, 27 Mar 2000 12:53:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE4415DDDE; Mon, 27 Mar 2000 12:53:56 -0500 (EST) Received: from malone.cisco.com (malone.cisco.com [171.68.225.99]) by segue.merit.edu (Postfix) with ESMTP id 541175DD9F for ; Mon, 27 Mar 2000 12:53:55 -0500 (EST) Received: from dkirsch.cisco.com (sj-dial-3-27.cisco.com [171.68.180.28]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA06955; Mon, 27 Mar 2000 09:53:46 -0800 (PST) Message-Id: <4.3.1.2.20000327125009.00b366c0@malone.cisco.com> X-Sender: dkirsch@malone.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 27 Mar 2000 12:52:56 -0500 To: , , "David Harrington" From: David Kirsch Subject: Re: Re-charter discussion In-Reply-To: <200003270448.UAA05756@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, et. al. Your statement that we've now, through the list, asked folks to put up their hand is right on. I'd figure if there was also time placed on agenda for this and maybe next meeting would be enough to "get the word out" and to give enough time for all respondants to put forth. The question that comes in my mind is how long to keep bringing in new submissions, but in reality is this really a problem? Say mid of the year someone brings in a new set of ideas that were good, we would accept them in for consideration right? Or is there some need to have a "cut off" timeframe for this "round" of discussion? Cheers, David K. At 03:14 PM 03/27/2000 -0800, Patrice Calhoun wrote: > >I must agree with David on this...even in some of the requirements > >documents that are now written we have stated that there is not one > >protocol that covers all our requirements. > > > >I also believe that while there has been discussion as to protocols, > >primarily outside of formal discussion, that it would be appropriate to > >make a formal solicitation from the upcoming meeting to allow any other > >inputs to be evaluated as well. Would that not be appropriate? That also > >would allow for inputs from other working bodies while still having IETF > >AAA WG doing it's work itself and not cross - relying on others (as has > >been pointed out on this thread). > >And where was this stated? I happen to know of one that does, in fact, >as far as I can tell, satisfy all requirements. > >I am not stating that only one should be selected, but I don't see the >need to specifically choose multiple protocols if a single one could >do the job. > > > > >Would such a path, including a formal call for submissions to be evaluated, > >be appropriate? > >How formal should this be? The requirements are in, if you have a protocol >please speak up. The reality is, no one will personally mail a giftbox to >all IETF engineers requesting protocol submission. Someone in this thread >already asked for people to put up their hands, that was good enough for >me. > >Once we know what all of the candidates are, we can then start documenting >whether they do, or don't, meet the requirements. > >PatC > >PatC > > > >Cheers, > > > >David K. > > > >At 11:24 AM 03/16/2000 -0500, David Harrington wrote: > >>Hi, > >> > >>I have a serious problem with the assumption that ONE protocol will meet > >>all these criteria, and that if ONE protocol doesn't meet all criteria > >>that we should design ONE protocol to meet all criteria. > >> > >>While we may have a stable requirements document, I don't think we are > >>ready to select ONE candidate protocol. I don't have a protocol on the > >>table, and don't plan to submit ONE for consideration. > >> > >>I think we might be better served by selecting a number of candidate > >>protocols that already exist that are best suited to specific > >>applications, and defining the glue to integrate them. This would allow > >>us to take advantage of best-of-breed solutions that have been > >>field-tested already. > >> > >>The method we are using of forcing any candidate to meet ALL the > >>requirements doesn't permit the selection of a group of protocols that > >>could be used together, with appropriate glue for standardization, to > >>meet a set of specific needs. > >> > >>dbh > >> > >>"Lipford, Mark" wrote: > >> > > >> > I have been watching these last few exchanges go back and forth. > >> > > >> > I agree that we need a "formal" set of requirements before we can > start the > >> > discussion. > >> > > >> > Based on the response that I have seen (or not seen) on this list on the > >> > requirements I-D I believe we have a very stable list of > requirements and > >> > recommend we DO start the discussion in Adelaide. I think it is a well > >> > understood process that development in general will usually start on new > >> > products (or protocols) prior to having a formalized requirements > document. > >> > I say we do the same thing. We have a very stable document that simply > >> > needs to have an RFC number attached to it (I know there is more to > it then > >> > that), but the essence of the document will not be changed. > >> > > >> > Let's have the re-charter discussion in Adelaide and let's kick-off the > >> > protocol debate. > >> > > >> > One of the responses on this thread indicated a need to start > working on a > >> > comparison document. Let's start that. As a user of the service I > >> would be > >> > happy to assist in providing a "users" thoughts on the protocols, but to > >> > date I know of only one protocol out there sitting and waiting, if > >> there are > >> > others please make them known so we can get started. > >> > > >> > I also agree with Matt on a couple of points. > >> > If there is agreement in Adelaide on a protocol let's get on with it > >> and not > >> > waste time. I too am frustrated at the time this is taking. I need a > >> > protocol I can deploy now and RADIUS simply does not meet my needs. > >> > > >> > I have seen nor heard anything that specifically states we cannot get > >> > started in Adelaide (or sooner by e-mail). > >> > > >> > Mark A. Lipford > >> > Manager, Wireless Industry Standards - Data > >> > Sprint PCS > >> > 8001 College Blvd.; Suite 210 > >> > Overland Park, KS 66210 > >> > (913) 664-8335 (office) > >> > (913) 664-8440 (fax) > >> > (913) 226-9060 (PCS) > >> > > >> > -----Original Message----- > >> > From: Matt Holdrege [mailto:holdrege@lucent.com] > >> > Sent: Wednesday, March 15, 2000 9:33 AM > >> > To: Randy Bush > >> > Cc: aaa-wg@merit.edu > >> > Subject: RE: Re-charter discussion > >> > > >> > At 07:26 AM 3/15/00 -0800, Randy Bush wrote: > >> > >what candidates are there? > >> > > >> > Good point. Can we ask (formally if necessary) the authors of any AAA > >> > protocol that thinks they meet the current requirements to stand up and > >> > raise their hand? > >> > > > >---------------------------------------------------------------------------- > >David Kirsch Cisco Systems, Inc. > >Consulting Engineering 13615 Dulles Technology Dr > >Office of the CTO Herndon, Virginia 20171 > >Desk #. 703.484.5761 Mobile #: 703.608.4927 > >CLLI: HRNDVADUDS0 > >---------------------------------------------------------------------------- > >http://www.NetAid.Org > >"The power to end extreme poverty" > > > > > > ---------------------------------------------------------------------------- David Kirsch Cisco Systems, Inc. Consulting Engineering 13615 Dulles Technology Dr Office of the CTO Herndon, Virginia 20171 Desk #. 703.484.5761 Mobile #: 703.608.4927 CLLI: HRNDVADUDS0 ---------------------------------------------------------------------------- http://www.NetAid.Org "The power to end extreme poverty" From owner-aaa-bof@merit.edu Tue Mar 28 01:18:49 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA15897 for ; Tue, 28 Mar 2000 01:18:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2D545DD95; Tue, 28 Mar 2000 01:16:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8C8365DDF2; Tue, 28 Mar 2000 01:16:52 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id F2D975DD95 for ; Tue, 28 Mar 2000 01:16:48 -0500 (EST) Received: from vaio (IDENT:root@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id WAA85289 for ; Mon, 27 Mar 2000 22:16:45 -0800 (PST) (envelope-from perl@lucent.com) Message-Id: <4.2.2.20000328152953.00adc840@mail.yikes.com> X-Sender: rdp@mail.yikes.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 28 Mar 2000 15:44:42 +0930 To: From: Richard Perlman Subject: Requirements and Protocol selection In-Reply-To: <01af01bf8e0f$b4832350$268939cc@ntdev.microsoft.com> References: <001401bf8dc8$97d75330$2096a8c0@bridgewatersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Given the pressure to move quickly with protocol definition, and possibly selection I want to be sure I have the right definition of requirements. To me "requirements" means features, functionality, services, etc. the protocol must have to be successful in use for present applications and for applications in the reasonably predictable future (whatever that is). The key point being that the requirement is grounded by an expected, not imagined, use. That is to say, a real requirement is not just something we think would be "cool to have" but something for which we see a real, foreseeable, need. I think this distinction is important. As we look at protocols that might serve as a future AAA standard protocol I want to be sure we have a good, workable protocol that is achievable, usable and generally implementable (As a client, server, broker or whatever). So, I suggest that as we review the final requirements documents we do so with a very critical eye and not be afraid to delete where necessary. This is not to say that we shouldn't have an idea of what might be desirable at some point in the not too near future. We should try to envision such things, and then make sure that whatever protocol we choose (DIAMETER, CIRCUMFERENCE, CIRCUMCISION, SPHERE, RHOMBUS or MOBIUS -- I like that last one, it seems to describe the AAA WG experience) is extensible and can grow and change as needed. Richard From owner-aaa-bof@merit.edu Fri Mar 31 16:03:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA25959 for ; Fri, 31 Mar 2000 16:03:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id B992C5DDF4; Fri, 31 Mar 2000 16:00:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A7ED65DDF2; Fri, 31 Mar 2000 16:00:52 -0500 (EST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by segue.merit.edu (Postfix) with ESMTP id 1FC825DDA9 for ; Fri, 31 Mar 2000 16:00:51 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id NAA27393; Fri, 31 Mar 2000 13:00:50 -0800 (PST) From: Chris_Cormier@3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id NAA22471; Fri, 31 Mar 2000 13:00:49 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 882568B3.00735FB4 ; Fri, 31 Mar 2000 13:00:11 -0800 X-Lotus-FromDomain: 3COM To: aboba@internaut.com, aaa-wg@merit.edu Message-ID: <882568B3.007312AA.00@hqoutbound.ops.3com.com> Date: Fri, 31 Mar 2000 12:57:17 -0800 Subject: Re: Revised Network Access Requirements doc Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul decided last Thursday to see how much fluid he could lose; i was averaginjg 8 to 10 liters of IV saline solution a day through Sunday evenig. I'm try to catch up with tis on the oh-so-exciting flight across the pacific, and on the way back. Since that gives me about 20 hours or free time, I should be able to get some stuff done. -paul --On Sunday, 13 February, 2000 13:53 -0800 Bernard Aboba wrote: > As a result of the interim meeting, we went through > another revision of the network access requirements > document. Although the revision is not yet done > (inputs are still needed from Paul K., John > Vollbrecht, Butch Anton, Steve Bellovin and > others), I thought it would be worth posting the > current state of the draft, to stimulate discussion. > > Thanks to Pat Calhoun, Dave Mitton and Steven Glass, > for leading the editing of this revision. > > http://www.drizzle.com/~aboba/AAA/REQTS/draft-ietf-aaa-na-reqts-02a.txt > > > From owner-aaa-bof@merit.edu Fri Mar 31 16:08:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA26032 for ; Fri, 31 Mar 2000 16:08:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FFB95DE03; Fri, 31 Mar 2000 16:06:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EE2115DE0C; Fri, 31 Mar 2000 16:06:50 -0500 (EST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by segue.merit.edu (Postfix) with ESMTP id B41545DE03 for ; Fri, 31 Mar 2000 16:06:14 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id NAA00883; Fri, 31 Mar 2000 13:06:13 -0800 (PST) From: Chris_Cormier@3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id NAA26687; Fri, 31 Mar 2000 13:06:08 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 882568B3.0073DCE5 ; Fri, 31 Mar 2000 13:05:31 -0800 X-Lotus-FromDomain: 3COM To: aboba@internaut.com Cc: aaa-wg@merit.edu Message-ID: <882568B3.00731067.00@hqoutbound.ops.3com.com> Date: Fri, 31 Mar 2000 12:57:06 -0800 Subject: Re: Revised Network Access Requirements doc Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA26032 Hello folks, All in all, the revised draft has improved remarkably from the first version. It was easier to read and understand. The requirements were more clear and the explanations better. I still have some comments... Bernard Aboba wrote: > > As a result of the interim meeting, we went through > another revision of the network access requirements > document. Although the revision is not yet done > (inputs are still needed from Paul K., John > Vollbrecht, Butch Anton, Steve Bellovin and > others), I thought it would be worth posting the > current state of the draft, to stimulate discussion. > > Thanks to Pat Calhoun, Dave Mitton and Steven Glass, > for leading the editing of this revision. > > http://www.drizzle.com/~aboba/AAA/REQTS/draft-ietf-aaa-na-reqts-02a.txt Here are some comments after I compared the na-reqts-01 to na-reqts-02a and read the interim meeting minutes more carefully: (My comments come mainly from the MIP point of view.) 1. Auditability This is left uncommented by the MIP WG. What does this mean? - MIP does not care whether the MN users get overcharged? - There is no exact decision about this requirement? - This requirementis not affecting MIP implementations, so no comments? Personally, I would place a 'MUST' here. Actually, I was a bit surprised about the non-repudiation vs auditability discussion in the interim meeting minutes. Is it really so, that non-repudiation is too strong a term here. In my opinion, auditability and verifiability are quite binary in nature: Either you can audit and verify something - or you can't. This approaches non-repudiation already, thus my wondering. 2. Scalability "[a] The AAA protocol must be capable of supporting millions of users, tens of thousands of simultaneous requests, and whereas possible should not be constrained to a small number of devices, proxies and brokers." I would rephrase this to: "... of simultaneous requests. The AAA architecture and protocol MUST NOT be constrained to a small number of devices, proxies or brokers." Well, in extreme cases also the "small number" should be better defined. ;) In that case, why not write: "... The AAA architecture and protocol MUST be capable of supporting tens of thousands of devices, AAA servers, proxies or brokers." This requirement is implicitly mentioned in RFC 2477, 2.4.3/Scalability. 3. Authentication Timing - latency "[b] Authentication Timing - latency round trip should be less than 100 ms." This is very much asked since only pinging from Helsinki/Finland to Munchen/Germany takes round-trip min/avg/max = 141.0/225.3/279.5 ms! Of course the <100ms is desired, but can any architecture/protocol that needs Internet achieve that in the next couple of years? Localized signaling solutions or privately held dedicated networks might achieve this performance, though. In this context the "grace period" before accounting starts becomes quite important again. As the number of devices and "transactions" increase it is very likely that the AAA system becomes slow. Grace period would easen the pain at least a bit. :) 4. Shared secret not required I think this on needs further clarification... What about stating that the trust and secure communication channels MUST be established either via shared secrets, or via other (add your enumerable set of possibilities here) means. At least IKE+IPSec can be used e.g. between service provider AAA equipment. Also other possibilities, like SSH tunnels / more generic secure tunnels might be worth defining as an option. It might be better not to say "not required", but to say what is actually required (and a list of optional ways to achieve that). And when protocol extensibility is required, it should not be a problem if we find more ways to do the thing later on. 5. Ability to carry service specific attributes Does this concern MIP when MIP signaling is incorporated inside AAA messages? (E.g. in the case of dynamic HA allocation?) For MIP, the requirement was "SHOULD". Wouldn't "MUST" be better here? In MIP AAA reqts, Ch.5. it says that AAA protocol needs extensions for carrying MIP signaling messages. 6. Unidirectional authentivation AAA Server/user The explanation is unclear. If mutual authentication is a must, why should we need something like this? I suggest this requirement to be removed. 7. Re-authentication on demand Can any AAA Server ask for this? What kind of authentication/authorization is involved in the re-authentication? If none is required, then anyone could require re-authentication and make a nice DoS to a roaming user. Existing session keys (for example9 could be used to authorize the re-authentication request. Well, I'm running out of time for today, but maybe it's best to stop here anyway to avoid jumbo messages. I hope even some of you managed it this far. Comments are most welcome! Tom -- Tom Weckström tweckstr@cc.hut.fi