From owner-aaa-wg@merit.edu Fri Oct 1 12:10:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17702 for ; Fri, 1 Oct 2004 12:10:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 333E9912FF; Fri, 1 Oct 2004 12:09:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D360A91303; Fri, 1 Oct 2004 12:09:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AF89912FF for ; Fri, 1 Oct 2004 12:09:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14D1184DD9; Fri, 1 Oct 2004 12:09:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from NEWSWEEPER.openet-telecom.lan (mail.openet-telecom.com [62.17.151.60]) by segue.merit.edu (Postfix) with ESMTP id 3A6E084E71 for ; Fri, 1 Oct 2004 12:09:20 -0400 (EDT) Received: from exc03.openet-dublin (exc03.openet-telecom.lan [10.0.2.193]) by NEWSWEEPER.openet-telecom.lan (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 1 Oct 2004 17:09:17 +0100 Content-class: urn:content-classes:message Subject: [AAA-WG]: FW: Typo in RFC3588? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2004 17:09:10 +0100 Message-ID: <8276FAA6D84AA54987B825CD51EDFAA62D402A@exc03.openet-dublin> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Typo in RFC3588? Thread-Index: AcSnyYp6CV8il3GtQaOwdJbe9PZjRgABwcew From: "Alan McNamee" To: Cc: "Alan McNamee" , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Please note the following. Regards, Alan. -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Friday, October 01, 2004 15:56 To: Alan McNamee Cc: pcalhoun@airespace.com Subject: Re: Typo in RFC3588? The "formal protocol" is to post a message to the AAA WG (aaa-wg@merit.edu). On Fri, 1 Oct 2004, Alan McNamee wrote: > Hello Pat, > > In reading 5.5.2 of RFC3588 I have noticed that on page 64 the=20 > description of the Device-Watchdog-Answer refers to an AVP=20 > "Original-State-Id". Is this a typo? I would have expected to see an=20 > "Origin-State-Id" AVP? > > If there is a more formal protocol for me to report these issues/check > have they already been reported can you please point me in the right=20 > direction. > > Kind Regards, > Alan. > > ---------------------------------------------------------------------- > -- > ------------ > Alan McNamee > > Software Architect, > Office of the CTO > 6 Beckett Way > Park West Business Park > Dublin 12 > Ireland > > Tel: +353 1 620 4600 > Fax: +353 1 620 4990 > > > > > ********************************************************************** > Scanned by Sophos Anti-Virus for Openet Telecom > *********** > > From owner-aaa-wg@merit.edu Fri Oct 1 12:33:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21979 for ; Fri, 1 Oct 2004 12:33:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7355912F0; Fri, 1 Oct 2004 12:32:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7462D912F4; Fri, 1 Oct 2004 12:32:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 403EE912F0 for ; Fri, 1 Oct 2004 12:32:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2ACFB84DD9; Fri, 1 Oct 2004 12:32:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from NEWSWEEPER.openet-telecom.lan (mail.openet-telecom.com [62.17.151.60]) by segue.merit.edu (Postfix) with ESMTP id 742A484D75 for ; Fri, 1 Oct 2004 12:32:14 -0400 (EDT) Received: from exc03.openet-dublin (exc03.openet-telecom.lan [10.0.2.193]) by NEWSWEEPER.openet-telecom.lan (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 1 Oct 2004 17:32:08 +0100 Content-class: urn:content-classes:message Subject: [AAA-WG]: Another Typo in RFC3588? Redirect-Host-Cache-Time MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A7D4.31F056B5" Date: Fri, 1 Oct 2004 17:32:08 +0100 Message-ID: <8276FAA6D84AA54987B825CD51EDFAA62D402C@exc03.openet-dublin> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Another Typo in RFC3588? Redirect-Host-Cache-Time Thread-Index: AcSn1B1k0udIQnBUQYWnwPMu0IQZqw== From: "Alan McNamee" To: Cc: "Alan McNamee" , Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4A7D4.31F056B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 The description of the message format for RAA on page 102 lists a "Redirect-Host-Cache-Time" AVP. Is this a typo? I would have expected this to be "Redirect-Max-Cache-Time". =20 Regards, Alan. =20 =20 ------------------------------------------------------------------------ ------------ Alan McNamee =20 Software Architect, Office of the CTO 6 Beckett Way Park West Business Park Dublin 12 Ireland =20 Tel: +353 1 620 4600 Fax: +353 1 620 4990 =20 =20 ********************************************************************** Scanned by Sophos Anti-Virus for Openet Telecom *********** ------_=_NextPart_001_01C4A7D4.31F056B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
The descr= iption of=20 the message format for RAA on page 102 lists a "Redirect-Host-Cache-Time" A= VP.=20 Is this a typo?
I would h= ave=20 expected this to be "Redirect-Max-Cache-Time".
 
Regards,
Alan.
 
 
------------------------------------------------------------------= ------------------
Alan McNamee
 
Software Architect,
Office of the CTO
6 Beckett Way
Park West Business Park
Dublin 12
Ireland
 
Tel:   +353 1 620= 4600
Fax:   +353 1 620= 4990
 
 


**********************************************************************
Scanned by Sophos Anti-Virus for Openet Telecom
***********
 ------_=_NextPart_001_01C4A7D4.31F056B5-- From owner-aaa-wg@merit.edu Fri Oct 1 20:19:32 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12608 for ; Fri, 1 Oct 2004 20:19:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5EEF091222; Fri, 1 Oct 2004 20:19:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C9789122B; Fri, 1 Oct 2004 20:19:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3FE691222 for ; Fri, 1 Oct 2004 20:19:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C7E6184FAB; Fri, 1 Oct 2004 20:19:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by segue.merit.edu (Postfix) with ESMTP id 862AD84F9B for ; Fri, 1 Oct 2004 20:19:19 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 01 Oct 2004 17:20:23 -0700 X-BrightmailFiltered: true Received: from gwzw2k01 (dhcp-64-101-41-112.cisco.com [64.101.41.112]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i920JF3c025820; Fri, 1 Oct 2004 17:19:15 -0700 (PDT) Reply-To: From: "Glen Zorn (gwz)" To: "'Alan McNamee'" , Cc: Subject: RE: [AAA-WG]: FW: Typo in RFC3588? Date: Fri, 1 Oct 2004 17:19:15 -0700 Message-ID: <014501c4a815$74324e50$70296540@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <8276FAA6D84AA54987B825CD51EDFAA62D402A@exc03.openet-dublin> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Alan McNamee wrote: > Please note the following. Actually, I think that the "formal protocol" is report the error to (see http://www.rfc-editor.org/errata.html). >=20 > Regards, > Alan. >=20 >=20 > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, October 01, 2004 15:56 > To: Alan McNamee > Cc: pcalhoun@airespace.com > Subject: Re: Typo in RFC3588? >=20 >=20 > The "formal protocol" is to post a message to the AAA WG > (aaa-wg@merit.edu).=20 >=20 > On Fri, 1 Oct 2004, Alan McNamee wrote: >=20 >> Hello Pat, >>=20 >> In reading 5.5.2 of RFC3588 I have noticed that on page 64 the >> description of the Device-Watchdog-Answer refers to an AVP >> "Original-State-Id". Is this a typo? I would have expected to see an >> "Origin-State-Id" AVP?=20 >>=20 >> If there is a more formal protocol for me to report these >> issues/check=20 >=20 >> have they already been reported can you please point me in the right >> direction.=20 >>=20 >> Kind Regards, >> Alan. >>=20 >> -------------------------------------------------------------------- -- >> --=20 >> ------------ >> Alan McNamee >>=20 >> Software Architect, >> Office of the CTO >> 6 Beckett Way >> Park West Business Park >> Dublin 12 >> Ireland >>=20 >> Tel: +353 1 620 4600 >> Fax: +353 1 620 4990 >>=20 >>=20 >>=20 >>=20 >> ******************************************************************** ** >> Scanned by Sophos Anti-Virus for Openet Telecom >> *********** From owner-aaa-wg@merit.edu Sat Oct 2 05:53:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07779 for ; Sat, 2 Oct 2004 05:53:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5D4F91223; Sat, 2 Oct 2004 05:53:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 816E59122C; Sat, 2 Oct 2004 05:53:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42AAF91223 for ; Sat, 2 Oct 2004 05:53:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B2C784FEB; Sat, 2 Oct 2004 05:53:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ind-iport-1.cisco.com (ind-iport-1-sec.cisco.com [64.104.129.9]) by segue.merit.edu (Postfix) with ESMTP id 3562984FDC for ; Sat, 2 Oct 2004 05:53:38 -0400 (EDT) Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 02 Oct 2004 15:42:08 +0530 X-BrightmailFiltered: true Received: from ind-mira-01.cisco.com (IDENT:mirapoint@ind-mira-01.cisco.com [64.104.129.12]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i929r4qX016464 for ; Sat, 2 Oct 2004 02:53:07 -0700 (PDT) Received: from cisco.com (dhcp-64-104-145-185.cisco.com [64.104.145.185]) by ind-mira-01.cisco.com (MOS 3.4.6-GR) with ESMTP id AFE79721; Sat, 2 Oct 2004 15:17:59 +0530 (IST) Message-ID: <415E7A9A.6080402@cisco.com> Date: Sat, 02 Oct 2004 15:23:30 +0530 From: Sumanth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Failover mechanism in DCCA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Apologies if this has been discussed already. From Section 5.7 Failure Procedures, seems to imply that DCCA client is managing failover to secondary servers and sometimes interpreting the protocol errors like DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY. These, I understand are more of BASE protocol functionalities and should be transparent to DCCA client. (Assuming DCCA would be layered on BASE) In scenarios where DCCA client talking to Agents, and an Agent could be serving the requests for a particular realm 3 hops away, do we need to start all over again to try the alternate secondary server which could have been reached from the same Agent ? Further, how would the DCCA client know which is the alternate server that needs to be tried ? As far as I see, DCCA should include Dest-Host AVP for the subsequent requests after initial CCA received *IF* failover_is_not_supported else it shouldn't include this AVP so that the BASE/Agents can do a failover to other servers in a given realm. But, with the above approach it is not guaranteed that we always try the server which replied with initial CCA before failing over to the other alternate servers. Regards, ~sumanth From owner-aaa-wg@merit.edu Sun Oct 3 18:45:17 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23982 for ; Sun, 3 Oct 2004 18:45:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CC8F9122D; Sun, 3 Oct 2004 01:28:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E8BF9122F; Sun, 3 Oct 2004 01:28:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A95C9122D for ; Sun, 3 Oct 2004 01:28:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45F1485167; Sun, 3 Oct 2004 01:28:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by segue.merit.edu (Postfix) with ESMTP id D407585179 for ; Sun, 3 Oct 2004 01:28:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i935IsQ18205; Sat, 2 Oct 2004 22:18:55 -0700 Date: Sat, 2 Oct 2004 22:18:54 -0700 (PDT) From: Bernard Aboba To: Sumanth Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Failover mechanism in DCCA In-Reply-To: <415E7A9A.6080402@cisco.com> Message-ID: References: <415E7A9A.6080402@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > These, I understand are more of BASE protocol functionalities and should > be transparent to DCCA client. (Assuming DCCA would be layered on BASE) The BASE failover facilities described in RFC 3539 operate only on the first hop, and assume that state is not being kept, and therefore that one AAA server is as good as another. This is not necessarily true for the DCCA application, which builds state on the Diameter client and server that may or may not be replicated to an alternative server. The result is that pure BASE failover functionality can result in failover to a DCCA server without the required state. This is why DCCA needs to be able to control the failover behavior via the CC-Session-Failover AVP. My understanding is that if this AVP is not set to FAILOVER_SUPPORTED then Diameter Base failover is turned off. > In scenarios where DCCA client talking to Agents, and an Agent could be > serving the requests for a particular realm 3 hops away, do we need to > start all over again to try the alternate secondary server which could > have been reached from the same Agent ? Further, how would the DCCA > client know which is the alternate server that needs to be tried ? Diameter clients utilize the Watchdog functionality defined in RFC 3539 to diagnose failures in the first hop. Unless a Diameter client receives an error message, it may be quite difficult for it to diagnose the cause of a failure beyond the first hop. In general, receipt of error messages is not guaranteed for all potential failure scenarios. > As far as I see, DCCA should include Dest-Host AVP for the subsequent > requests after initial CCA received *IF* failover_is_not_supported else > it shouldn't include this AVP so that the BASE/Agents can do a failover > to other servers in a given realm. In general, RFC 3539 tries to avoid failover while segments are still in flight since this violates the law of "conservation of packets". That is why Diameter DCCA can terminate service early (prior to expiration of the minimum Tw timer) but does not initiate a new request unless a protocol error has been received, indicating that segments are no longer in flight. This enables DCCA to maintain conservative behavior. > But, with the above approach it is not guaranteed that we always try the > server which replied with initial CCA before failing over to the other > alternate servers. I'm also not sure how this approach can avoid multiple failovers and violation of "conservation of packets". From reminder@computeradmin.org Tue Oct 5 08:36:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22043; Tue, 5 Oct 2004 08:36:20 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEohX-0004MM-6x; Tue, 05 Oct 2004 08:45:57 -0400 Received: from c-67-165-237-247.client.comcast.net ([67.165.237.247]) by mx2.foretec.com with smtp (Exim 4.24) id 1CEoYD-0007GK-0K; Tue, 05 Oct 2004 08:36:17 -0400 Received: from [113.219.90.19] by c-67-165-237-247.client.comcast.net with SMTP; Tue, 05 Oct 2004 06:38:57 -0700 Message-ID: <66yk77a0z1v8eb6-5-$e-z@yi5.q1w419> From: "Administrator" To: aaa-archive@ietf.org Subject: ADV: Reminder for October 6, 2004 Date: Tue, 05 Oct 04 06:38:57 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="83E2550_3852" X-Spam-Score: 22.9 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. --83E2550_3852 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Special Notice: We are pleased to inform you that the members and staff of your nonprofit organization have been selected to receive 50% off discounts towards brand new desktop computers. Through this program, nonprofits and their members and staff are offered top of the line Name-Brand Desktop Computers at more than 50% List Price to all who: Call 1-800-795-9144 by 6 P.M. Wednesday, October 6, 2004 and ask for Department D. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-9144 by 5 P.M. Wednesday, October 6, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $247 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-9144 by 5 P.M. Wednesday, October 6, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department D. Call Avtech Direct 1-800-795-9144 before 5 P.M. Wednesday, October 6, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --83E2550_3852-- From admin@staffadministrator.com Thu Oct 14 23:30:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04226; Thu, 14 Oct 2004 23:30:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIIyd-0004Ks-Ut; Thu, 14 Oct 2004 23:42:00 -0400 Received: from [200.232.87.194] (helo=200-232-87-194.fts.com.br) by mx2.foretec.com with smtp (Exim 4.24) id 1CIInI-00044X-KV; Thu, 14 Oct 2004 23:30:17 -0400 Received: from t4.krwhgm.org (HELO hke) [122.26.191.212] by 200-232-87-194.fts.com.br id <8498135-24441>; Thu, 14 Oct 2004 21:25:33 -0700 Message-ID: <12$2b$$yj-7p$5--3$$-$o-up@obg1xg2zb> From: "Administrator" To: dhcipv6-archive@ietf.org Subject: ADV: Staff Annoucement Date: Thu, 14 Oct 04 21:25:33 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A1F_AE1E72F9.ABA" X-Spam-Score: 21.0 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --A1F_AE1E72F9.ABA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Monday, October 18, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Monday, October 18, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Monday, October 18, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Monday, October 18, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Monday, October 18, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --A1F_AE1E72F9.ABA-- From owner-aaa-wg@merit.edu Wed Oct 20 17:20:53 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27973 for ; Wed, 20 Oct 2004 17:20:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 115B49120E; Wed, 20 Oct 2004 17:20:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF08891266; Wed, 20 Oct 2004 17:20:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 925FE9120E for ; Wed, 20 Oct 2004 17:20:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E6A8B1FFC; Wed, 20 Oct 2004 17:20:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.taoofmac.com (unknown [213.30.75.10]) by segue.merit.edu (Postfix) with ESMTP id A0E34B2003 for ; Wed, 20 Oct 2004 17:20:44 -0400 (EDT) Received: from [192.168.42.42] ([192.168.42.42]) by mail.taoofmac.com (8.11.6/8.11.6) with ESMTP id i9KLKYU08163 for ; Wed, 20 Oct 2004 22:20:34 +0100 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rui Carmo Subject: Re: [AAA-WG]: Re: AAA URI draft Date: Wed, 20 Oct 2004 22:20:33 +0100 To: aaa-wg@merit.edu X-Mailer: Apple Mail (2.619) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sep 10, 2004, at 11:28 PM, Roy T. Fielding wrote: > but as near as I can tell, the only resources ever provided by those > protocols are the service points (i.e., the fact that there is an AAA > listener at that address). Why, then, is there a desire for a grab-bag > identification scheme like "aaa", which hides the most important bits > of information at the end of the URI, when the same thing can be > better accomplished by specific URI schemes for each service? > > In other words, what I would propose is the following: > > d = "diameter" "://" authority ; Diameter/sctp > d-tcp = "diameter.tcp" "://" authority ; Diameter/tcp > d-tls = "diameter.tls" "://" authority ; Diameter/tls/sctp > dtc = "diameter.tls.tcp" "://" authority ; Diameter/tls/tcp > > r = "radius" "://" authority ; RADIUS/udp > > t = "tacacs" "://" authority ; TACACS+/sctp > t-udp = "tacacs.udp" "://" authority ; TACACS+/udp > > Note that the above removes all of the complexity described in > section 3 regarding the various combinations of AAA protocol, > transport, and session-based security that are not allowed. If you > simply define the URI schemes such that illegitimate combinations > aren't even an option, then you don't have to require that > applications keep track of what combination of parameters > are allowed. Likewise, all of the aliases (multiple URIs for the > same service) are removed by specifying that the short scheme > defines the most common protocol case (just as the "http" scheme > defines HTTP over TCP, not HTTP over any transport). I like it. It is consistent with the need to manage different sorts of AAA servers during the migration to Diameter and can cater for all the usual O&M issues (like custom port numbers, defaults, etc.) in a non-ambiguous way that will minimize the chances for human error. > Furthermore, if we later discover that there are more resources > hidden within the Diameter, TACACS+, and RADIUS servers beyond > the mere existence of the service points, then all we need to > do is add a path to the URI definition and those new services > can be used by other information systems beyond AAA. Yes, and applications handling the URI, as you put it quite nicely, can process it in a standard way (with the proper validations, I can envision using the URI as an XPath into a XML configuration file, etc.). Rui Carmo From owner-aaa-wg@merit.edu Thu Oct 21 03:13:51 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16556 for ; Thu, 21 Oct 2004 03:13:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEEF99120D; Thu, 21 Oct 2004 03:13:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C88791218; Thu, 21 Oct 2004 03:13:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49FAD9120D for ; Thu, 21 Oct 2004 03:13:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3271785A40; Thu, 21 Oct 2004 03:13:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 2BE2785A5F for ; Thu, 21 Oct 2004 03:13:42 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9L7Dco03351; Thu, 21 Oct 2004 10:13:38 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 10:04:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9L74VU9008352; Thu, 21 Oct 2004 10:04:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Qnl2VA; Thu, 21 Oct 2004 10:03:25 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9L73JS05771; Thu, 21 Oct 2004 10:03:19 +0300 (EET DST) Received: from [172.21.39.161] ([172.21.39.161]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 10:02:53 +0300 Message-ID: <41775F1C.2090700@nokia.com> Date: Thu, 21 Oct 2004 10:02:52 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Rui Carmo Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: AAA URI draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2004 07:02:53.0153 (UTC) FILETIME=[FBF86510:01C4B73B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rui: I am not the advocate of any proposal, but I will give you my opinion on this. 1) The aaa URI scheme is already specified in RFC 3588 (though not registered with IANA). Although I personally don't like URIs that are not protocol specific, this is a common practice today. Think of the mailto, im and pres URI schemes for e-mail, instant messaging and pressence, respectively. All of them are protocol independent. 2) As far as I know, it is not feasible to expose the combination of protocol/transport/security in the URI scheme itself, because the combination will be growing with time and makes unfeasible to have a future compatible deployment of Diameter. As far as I know, the IESG has typically allowed to differentiate the security requirements in the URI, but not other aspects such as the transport protocol. For instance, http and https URIs differentiate the security aspects of HTTP. Well, HTTP runs over TCP so it is not a big issue. But take as an example the sip URI scheme. SIP can run over TCP, UDP, and SCTP. There are not such thing as sip.tcp, sip.udp, sip.sctp, sips.tcp, sips.sctp URI schemes. Instead, there are only sip and sips URI schemes. Therefore my opinion is that we shouldn't go in a direction where the transport protocol is visible in the URI scheme. I think we should try to keep the aaa and aaas URI schemes. 3) Having said that, I agree with Roy that the combinations of different AAA protocols, transport protocols and security protocols looks a bit complicated. I wonder if we could make things easier by defining a diameter and diameters URI schemes. If we go in this direction I think we would have to do the following: - Make the aaa/aaas URI schemes protocol agnostic; remove all the parameters (including protocol and transport). - Define diameter and diameters URI schemes. Make them protocol specific, obviously. Add a parameter that specifies the transport. - Somebody (we could do it if assigned) should do similar thing with radius URI scheme. - We should define guidelines or even procedures to translate between aaa/aaas URI schemes and their corresponding diameter/radius URI schemes. Comments? BR, Miguel Rui Carmo wrote: > > On Sep 10, 2004, at 11:28 PM, Roy T. Fielding wrote: > >> but as near as I can tell, the only resources ever provided by those >> protocols are the service points (i.e., the fact that there is an AAA >> listener at that address). Why, then, is there a desire for a grab-bag >> identification scheme like "aaa", which hides the most important bits >> of information at the end of the URI, when the same thing can be >> better accomplished by specific URI schemes for each service? >> >> In other words, what I would propose is the following: >> >> d = "diameter" "://" authority ; Diameter/sctp >> d-tcp = "diameter.tcp" "://" authority ; Diameter/tcp >> d-tls = "diameter.tls" "://" authority ; Diameter/tls/sctp >> dtc = "diameter.tls.tcp" "://" authority ; Diameter/tls/tcp >> >> r = "radius" "://" authority ; RADIUS/udp >> >> t = "tacacs" "://" authority ; TACACS+/sctp >> t-udp = "tacacs.udp" "://" authority ; TACACS+/udp >> >> Note that the above removes all of the complexity described in >> section 3 regarding the various combinations of AAA protocol, >> transport, and session-based security that are not allowed. If you >> simply define the URI schemes such that illegitimate combinations >> aren't even an option, then you don't have to require that >> applications keep track of what combination of parameters >> are allowed. Likewise, all of the aliases (multiple URIs for the >> same service) are removed by specifying that the short scheme >> defines the most common protocol case (just as the "http" scheme >> defines HTTP over TCP, not HTTP over any transport). > > > I like it. It is consistent with the need to manage different sorts of > AAA servers during the migration to Diameter and can cater for all the > usual O&M issues (like custom port numbers, defaults, etc.) in a > non-ambiguous way that will minimize the chances for human error. > >> Furthermore, if we later discover that there are more resources >> hidden within the Diameter, TACACS+, and RADIUS servers beyond >> the mere existence of the service points, then all we need to >> do is add a path to the URI definition and those new services >> can be used by other information systems beyond AAA. > > > Yes, and applications handling the URI, as you put it quite nicely, can > process it in a standard way (with the proper validations, I can > envision using the URI as an XPath into a XML configuration file, etc.). > > Rui Carmo > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Thu Oct 21 04:41:34 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21663 for ; Thu, 21 Oct 2004 04:41:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E478F91218; Thu, 21 Oct 2004 04:41:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B42819126D; Thu, 21 Oct 2004 04:41:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F4F491218 for ; Thu, 21 Oct 2004 04:41:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A62CB1C87; Thu, 21 Oct 2004 04:41:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtpoutuk02.marconi.com (smtpoutuk02.marconi.com [128.87.251.113]) by segue.merit.edu (Postfix) with ESMTP id 76DC7B1C69 for ; Thu, 21 Oct 2004 04:41:20 -0400 (EDT) Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id i9L8USuh029278 for ; Thu, 21 Oct 2004 09:30:29 +0100 (envelope-from ian.elz@marconi.com) Subject: [AAA-WG]: One off Accounting Events in an Accounting Session To: aaa-wg@merit.edu X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Ian Elz" Date: Thu, 21 Oct 2004 09:40:06 +0100 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 21/10/2004 09:41:05 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk I have been studying the Diameter Base Protocol RFC (RFC 3588) and wish to determine if it is possible to send 'one off' Accounting transactions with in an open Diameter session. Section 9.8.1 of RFC3588 states that there are 4 different Accounting-Record-Type AVP values EVENT_RECORD START_RECORD INTERIM_RECORD STOP_RECORD After starting a Diameter Session using the START_RECORD value is it possible to send additional 'one off' transactions within the same session ? The Session will use INTERIM_RECORDs to update cumulative data that gets overwritten, as specified within the RFC, but I have a requirement to be able to send one or more transactions within the same session relating to cumulative data that does not get overwritten, and for which INTERIM_RECORDs are therefore inappropriate. The current belief is that this is not possible and that the use of the Accounting-Sub-Session-Id AVP will be required with the conventional data being passed in one sub-session (possibly sub-session 0) and each of the new transactions being sent in a separate sub-session with Accounting-Record-Type EVENT_RECORD. Can I have confirmation as to whether this is the correct approach? Furthermore, it would appear that it is necessary to know in advance that you are going to use sub-sessions. The RFC says that the absence of the Accounting-Sub-Session-Id AVP implies that no sub-sessions are in use. This means that it is not possible to start a session without the presence of the sub-session AVP and subsequently start using sub-sessions as it is not possible to send INTERIM_RECORDs on the original session without implying that no sub-sessions are in use. Is this interpretation of the specification correct? Ian Elz From owner-aaa-wg@merit.edu Thu Oct 21 05:39:58 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24049 for ; Thu, 21 Oct 2004 05:39:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E77969126D; Thu, 21 Oct 2004 05:39:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6F5691271; Thu, 21 Oct 2004 05:39:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92C859126D for ; Thu, 21 Oct 2004 05:39:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 739FA858F8; Thu, 21 Oct 2004 05:39:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B00698582D for ; Thu, 21 Oct 2004 05:39:51 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4CC158982E; Thu, 21 Oct 2004 12:39:35 +0300 (EEST) Message-ID: <41778375.6060300@kolumbus.fi> Date: Thu, 21 Oct 2004 12:37:57 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Elz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: One off Accounting Events in an Accounting Session References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ian Elz wrote: > Section 9.8.1 of RFC3588 states that there are 4 different > Accounting-Record-Type AVP values > > EVENT_RECORD > START_RECORD > INTERIM_RECORD > STOP_RECORD > > After starting a Diameter Session using the START_RECORD value is it > possible to send additional 'one off' transactions within the same session > ? The Session will use INTERIM_RECORDs to update cumulative data that gets > overwritten, as specified within the RFC, but I have a requirement to be > able to send one or more transactions within the same session relating to > cumulative data that does not get overwritten, and for which > INTERIM_RECORDs are therefore inappropriate. Ok. > The current belief is that this is not possible and that the use of the > Accounting-Sub-Session-Id AVP will be required with the conventional data > being passed in one sub-session (possibly sub-session 0) and each of the > new transactions being sent in a separate sub-session with > Accounting-Record-Type EVENT_RECORD. You could do this, or you could also have the conventional data as the top level records (no sub session AVP) and then every time you have some transactions you send a single EVENT_RECORD with the sub session AVP set to value. > Can I have confirmation as to whether this is the correct approach? > > Furthermore, it would appear that it is necessary to know in advance that > you are going to use sub-sessions. The RFC says that the absence of the > Accounting-Sub-Session-Id AVP implies that no sub-sessions are in use. This > means that it is not possible to start a session without the presence of > the sub-session AVP and subsequently start using sub-sessions as it is not > possible to send INTERIM_RECORDs on the original session without implying > that no sub-sessions are in use. Hmm... perhaps the language is a bit unclear. My interpretation of the intent of the text is that if you send a record without the sub session AVP then that record does not belong to a sub session (no subsessions are in use for THIS record), but that other sub sessions could still be in progress. But if you send the STOP_RECORD for the top-level session then it also implicitly closes all subsessions. What do others think? --Jari From owner-aaa-wg@merit.edu Thu Oct 21 08:05:33 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11874 for ; Thu, 21 Oct 2004 08:05:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5750C91272; Thu, 21 Oct 2004 08:05:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26BDC91273; Thu, 21 Oct 2004 08:05:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97DEE91272 for ; Thu, 21 Oct 2004 08:05:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C9E2B1C10; Thu, 21 Oct 2004 08:05:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis437.omnitel.it (mailout-1.omnitel.it [194.20.77.121]) by segue.merit.edu (Postfix) with ESMTP id 58DE9B1BED for ; Thu, 21 Oct 2004 08:05:15 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i9LC5Dx1026891 for ; Thu, 21 Oct 2004 14:05:13 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.195]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Oct 2004 14:05:13 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: One off Accounting Events in an Accounting Session X-mimeole: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 21 Oct 2004 14:05:13 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906F2CDB5@OMIMEXO06.omnitel.it> Thread-topic: [AAA-WG]: One off Accounting Events in an Accounting Session Thread-index: AcS3Ue7Xz2F/DHe9TEqg9gNoL2g08wAFBAZA From: "STURA Marco Consultant" To: "Jari Arkko" , "Ian Elz" Cc: X-OriginalArrivalTime: 21 Oct 2004 12:05:13.0304 (UTC) FILETIME=[3857C580:01C4B766] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Can I have confirmation as to whether this is the correct approach? >=20 > Furthermore, it would appear that it is necessary to know in advance that > you are going to use sub-sessions. The RFC says that the absence of the > Accounting-Sub-Session-Id AVP implies that no sub-sessions are in use. This > means that it is not possible to start a session without the presence of > the sub-session AVP and subsequently start using sub-sessions as it is not > possible to send INTERIM_RECORDs on the original session without implying > that no sub-sessions are in use. Hmm... perhaps the language is a bit unclear. My interpretation of the intent of the text is that if you send a record without the sub session AVP then that record does not belong to a sub session (no subsessions are in use for THIS record), but that other sub sessions could still be in progress. But if you send the STOP_RECORD for the top-level session then it also implicitly closes all subsessions. What do others think? [MSt] This is my interpretation as well. Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Jari Arkko Sent: Thursday, October 21, 2004 11:38 AM To: Ian Elz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: One off Accounting Events in an Accounting Session Ian Elz wrote: > Section 9.8.1 of RFC3588 states that there are 4 different > Accounting-Record-Type AVP values >=20 > EVENT_RECORD > START_RECORD > INTERIM_RECORD > STOP_RECORD >=20 > After starting a Diameter Session using the START_RECORD value is it > possible to send additional 'one off' transactions within the same session > ? The Session will use INTERIM_RECORDs to update cumulative data that gets > overwritten, as specified within the RFC, but I have a requirement to be > able to send one or more transactions within the same session relating to > cumulative data that does not get overwritten, and for which > INTERIM_RECORDs are therefore inappropriate. Ok. > The current belief is that this is not possible and that the use of the > Accounting-Sub-Session-Id AVP will be required with the conventional data > being passed in one sub-session (possibly sub-session 0) and each of the > new transactions being sent in a separate sub-session with > Accounting-Record-Type EVENT_RECORD. You could do this, or you could also have the conventional data as the top level records (no sub session AVP) and then every time you have some transactions you send a single EVENT_RECORD with the sub session AVP set to value. > Can I have confirmation as to whether this is the correct approach? >=20 > Furthermore, it would appear that it is necessary to know in advance that > you are going to use sub-sessions. The RFC says that the absence of the > Accounting-Sub-Session-Id AVP implies that no sub-sessions are in use. This > means that it is not possible to start a session without the presence of > the sub-session AVP and subsequently start using sub-sessions as it is not > possible to send INTERIM_RECORDs on the original session without implying > that no sub-sessions are in use. Hmm... perhaps the language is a bit unclear. My interpretation of the intent of the text is that if you send a record without the sub session AVP then that record does not belong to a sub session (no subsessions are in use for THIS record), but that other sub sessions could still be in progress. But if you send the STOP_RECORD for the top-level session then it also implicitly closes all subsessions. What do others think? --Jari From owner-aaa-wg@merit.edu Thu Oct 21 08:44:19 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18947 for ; Thu, 21 Oct 2004 08:44:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B47391216; Thu, 21 Oct 2004 08:44:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38D8D91273; Thu, 21 Oct 2004 08:44:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 024B591216 for ; Thu, 21 Oct 2004 08:44:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2232B1C43; Thu, 21 Oct 2004 08:44:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id E8D42B1C7F for ; Thu, 21 Oct 2004 08:44:10 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LCi6316907; Thu, 21 Oct 2004 15:44:07 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 15:40:43 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9LCehNZ030653; Thu, 21 Oct 2004 15:40:43 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00awslGQ; Thu, 21 Oct 2004 15:40:41 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LCeda21597; Thu, 21 Oct 2004 15:40:39 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:40:36 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:40:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: One off Accounting Events in an Accounting Session Date: Thu, 21 Oct 2004 15:40:36 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D1FFDC6@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: One off Accounting Events in an Accounting Session Thread-Index: AcS3U5j9Y0bfMgkOQF65Nz5aBv/NFwAF38NQ From: To: , Cc: X-OriginalArrivalTime: 21 Oct 2004 12:40:37.0893 (UTC) FILETIME=[2AB25350:01C4B76B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Furthermore, it would appear that it is necessary to know in advance = that > > you are going to use sub-sessions. The RFC says that the absence of = the > > Accounting-Sub-Session-Id AVP implies that no sub-sessions are in = use. This > > means that it is not possible to start a session without the = presence of > > the sub-session AVP and subsequently start using sub-sessions as it = is not > > possible to send INTERIM_RECORDs on the original session without = implying > > that no sub-sessions are in use. >=20 > Hmm... perhaps the language is a bit unclear. My interpretation > of the intent of the text is that if you send a record without > the sub session AVP then that record does not belong to a sub > session (no subsessions are in use for THIS record), but > that other sub sessions could still be in progress. But if > you send the STOP_RECORD for the top-level session then it > also implicitly closes all subsessions. >=20 > What do others think? This is my interpretation as well. John From owner-aaa-wg@merit.edu Thu Oct 21 09:11:21 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25545 for ; Thu, 21 Oct 2004 09:11:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1984D91273; Thu, 21 Oct 2004 09:11:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D306991275; Thu, 21 Oct 2004 09:11:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EF0091273 for ; Thu, 21 Oct 2004 09:11:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CEF2B1C3D; Thu, 21 Oct 2004 09:11:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 381D1B1BD0 for ; Thu, 21 Oct 2004 09:11:11 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LDB5e21656; Thu, 21 Oct 2004 16:11:05 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 16:10:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9LDARbU031263; Thu, 21 Oct 2004 16:10:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00KdJdWD; Thu, 21 Oct 2004 16:10:10 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LCjqa26530; Thu, 21 Oct 2004 15:45:52 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:45:51 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:45:51 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:45:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Re: AAA URI draft Date: Thu, 21 Oct 2004 15:45:49 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D1FFDC7@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: AAA URI draft Thread-Index: AcSXhZSY0d8ezHNRSKCBzLxflmE1Mwf5bSGQ From: To: , Cc: X-OriginalArrivalTime: 21 Oct 2004 12:45:50.0120 (UTC) FILETIME=[E4CC6280:01C4B76B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Roy, At a high-level, the AAA URI scheme was introduce in RFC3588 to be able to support NAPTR records for Diameter peer discovery - section 5.2. =20 Advice was given to follow what SIP does, and so the AAA URI scheme was based upon SIP. I am not sure right now if a hierarchical model is warranted. I'm curious to see if the WG has any opinion if there needs to be=20 an expansion in the use of the Diameter URI for other purposes. thanks, John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Roy T. Fielding > Sent: 11 September, 2004 01:28 > To: aaa-wg@merit.edu > Cc: uri@w3.org > Subject: [AAA-WG]: Re: AAA URI draft >=20 >=20 > Here are my comments regarding the AAA URI draft >=20 > http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt >=20 > update to RFC 3588. Sorry for the late review. >=20 > The basic premise of this update, namely >=20 > RFC 3588 [RFC3588] describes the Diameter base protocol for > authentication, authorization and accounting purposes. The RFC > provides for the existence of a DiameterURI AVP that contains a = "aaa" > or "aaas" URI. That definition of the "aaa" and "aaas" URI = schemes > follows the so-called hierarchical model specified in RFC 2396 > [RFC2396], although aaa/aaas resources do not point to = hierarchical > resources. >=20 > appears to be incorrect. For one thing, use of a namespace delegation > mechanism like DNS within the scheme is inherently hierarchical in > nature and benefits from using the common syntax forms. Furthermore, > if Diameter is actually a deployed protocol, an arbitrary change in > syntax to an existing scheme would significantly impact=20 > interoperability. >=20 > What is more problematic, however, is that the "aaa" and "aaas" > schemes seem to have been defined without a clear indication of > what is being identified: >=20 > RFC 3588 [RFC3588] does not provide semantics for the > "aaas" URI nor it provide instructions to IANA to register any of > those URI schemes in the official IANA registry of URI schemes. >=20 > Unfortunately, the new draft doesn't really define what kind of > resources are being identified either. It only says >=20 > Both the "aaa" and the "aaas" URI schemes are used to identify > resources related to authentication, authorization and accounting > (AAA) functions that are accessed with AAA protocols such as = RADIUS > [RFC2865] or Diameter [RFC3588]. >=20 > but as near as I can tell, the only resources ever provided by those > protocols are the service points (i.e., the fact that there is an AAA > listener at that address). Why, then, is there a desire for a = grab-bag > identification scheme like "aaa", which hides the most important bits > of information at the end of the URI, when the same thing can be > better accomplished by specific URI schemes for each service? >=20 > In other words, what I would propose is the following: >=20 > d =3D "diameter" "://" authority ; Diameter/sctp > d-tcp =3D "diameter.tcp" "://" authority ; Diameter/tcp > d-tls =3D "diameter.tls" "://" authority ; = Diameter/tls/sctp > dtc =3D "diameter.tls.tcp" "://" authority ; = Diameter/tls/tcp >=20 > r =3D "radius" "://" authority ; RADIUS/udp >=20 > t =3D "tacacs" "://" authority ; TACACS+/sctp > t-udp =3D "tacacs.udp" "://" authority ; TACACS+/udp >=20 > Note that the above removes all of the complexity described in > section 3 regarding the various combinations of AAA protocol, > transport, and session-based security that are not allowed. If you > simply define the URI schemes such that illegitimate combinations > aren't even an option, then you don't have to require that > applications keep track of what combination of parameters > are allowed. Likewise, all of the aliases (multiple URIs for the > same service) are removed by specifying that the short scheme > defines the most common protocol case (just as the "http" scheme > defines HTTP over TCP, not HTTP over any transport). >=20 > Furthermore, if we later discover that there are more resources > hidden within the Diameter, TACACS+, and RADIUS servers beyond > the mere existence of the service points, then all we need to > do is add a path to the URI definition and those new services > can be used by other information systems beyond AAA. >=20 > A FAQ about URI scheme definitions is why doesn't the port component > in authority come with parameterization, similar to that described > in the draft for the aaa and aaas schemes? The reason is because > applications use URI schemes as a hook by which to select modular > handlers for the processing of requests. Therefore, placing that > distinction in the scheme allows handlers for different transports > to be developed and deployed independently. In contrast, embedding > access parameters within a URI forces the application to choose > either a generic handler that may be incapable of handling the URI, > or to hard-code inspection of the URI path prior to URI handling > (effectively breaking the orthogonality principle that is the > central point of URI design). >=20 >=20 > Cheers, >=20 > Roy T. Fielding > Chief Scientist, Day Software >=20 >=20 From owner-aaa-wg@merit.edu Thu Oct 21 09:12:36 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25657 for ; Thu, 21 Oct 2004 09:12:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3434091275; Thu, 21 Oct 2004 09:12:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01A9491276; Thu, 21 Oct 2004 09:12:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B93AC91275 for ; Thu, 21 Oct 2004 09:12:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F9ADB1C2B; Thu, 21 Oct 2004 09:12:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id DE59E859EF for ; Thu, 21 Oct 2004 09:12:30 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LDCR304297; Thu, 21 Oct 2004 16:12:27 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 16:06:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9LD6RvE009999; Thu, 21 Oct 2004 16:06:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00hchV7X; Thu, 21 Oct 2004 16:05:50 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LCmPS04176; Thu, 21 Oct 2004 15:48:25 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:48:24 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:48:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Re: AAA URI draft Date: Thu, 21 Oct 2004 15:48:24 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D1FFDC8@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: AAA URI draft Thread-Index: AcS26s8I+zhCj8+eSAWQ8XiRt4rfRAAgUgeQ From: To: , X-OriginalArrivalTime: 21 Oct 2004 12:48:24.0956 (UTC) FILETIME=[41167BC0:01C4B76C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Rui, > > Note that the above removes all of the complexity described in > > section 3 regarding the various combinations of AAA protocol, > > transport, and session-based security that are not allowed. If you > > simply define the URI schemes such that illegitimate combinations > > aren't even an option, then you don't have to require that > > applications keep track of what combination of parameters > > are allowed. Likewise, all of the aliases (multiple URIs for the > > same service) are removed by specifying that the short scheme > > defines the most common protocol case (just as the "http" scheme > > defines HTTP over TCP, not HTTP over any transport). >=20 > I like it. It is consistent with the need to manage different sorts of = > AAA servers during the migration to Diameter and can cater for all the = > usual O&M issues (like custom port numbers, defaults, etc.) in a=20 > non-ambiguous way that will minimize the chances for human error. >=20 > > Furthermore, if we later discover that there are more resources > > hidden within the Diameter, TACACS+, and RADIUS servers beyond > > the mere existence of the service points, then all we need to > > do is add a path to the URI definition and those new services > > can be used by other information systems beyond AAA. >=20 > Yes, and applications handling the URI, as you put it quite nicely, = can=20 > process it in a standard way (with the proper validations, I can=20 > envision using the URI as an XPath into a XML configuration file,=20 > etc.). Before expanding the use of the URI, I'd like to get some input on=20 how the WG feels about this. Is this functionality needed? Also, it might be useful to get some input from RADIUS folks, etc. thanks, John From owner-aaa-wg@merit.edu Fri Oct 22 03:54:10 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09748 for ; Fri, 22 Oct 2004 03:54:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E38DB9121F; Fri, 22 Oct 2004 03:54:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B125D91285; Fri, 22 Oct 2004 03:54:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 358EA9121F for ; Fri, 22 Oct 2004 03:53:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15AFFB1E20; Fri, 22 Oct 2004 03:53:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id 52C01B1E12 for ; Fri, 22 Oct 2004 03:53:58 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 22 Oct 2004 09:53:48 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Oct 2004 09:53:46 +0200 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FDD1@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org, aaa-wg@merit.edu Cc: miguel.an.garcia@nokia.com Subject: [AAA-WG]: drafts-sterman-aaa-sip-04 is available Date: Fri, 22 Oct 2004 09:53:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk An updated draft of draft-sterman-aaa-sip is available: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt Changes: Issue 3: 1) Abstract new text: 'Several protocols borrow the syntax and authentication mechanisms from the Hypertext Transfer Protocol, HTTP. This document specifies an extension to RADIUS that allows a RADIUS client in a HTTP-style server, upon reception of a request, retrieve and compute Digest authentication information from a RADIUS server. Additionally, a scenario describing the authentication of a user emitting a HTTP-style request is provided.' 2) body digest renamed to Digest-Entity-Body-Hash 3) figures in attribute description only one figure for all attributes 4) mentioning of early number assignments removed 5) DIAMETER -> Diameter 6) IANA request added "This document serves as IANA registration request for ..." 7) horrible examples shortened and fixed Issue 4: 1) Attribute reuse removed attribute reuse, introduced new attributes Issue 5: 1) Digest-Stale Use is now mandatory if server chooses nonces. 2) Typos Issue 6: 1) Overview too short added overview section, rearranged document structure 1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 6 1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 7 2) missing explanation for pre-computed hashes new text: 'However, when using AKA [RFC3310] the nonce is partially derived from a precomputed authentication vector. These authentication vectors are often stored centrally.' 3) unclear defintion of 'secured connection' added a reference to Security Considerations, added explanation in Security Considerations Issue 7: Use of Message Authenticator should be mandatory RfC 2869 is informational. I see that it is useful but I hesitate to make it mandatory. new text: 'Informational RfC 3579 [RFC3579], section 3.2 describes a Message-Authenticator attribute which MAY be used to protect the integrity of RADIUS messages.' Issue 8: Rspauth generation not possible if RADIUS server chooses nonces and qop=auth-int In contrast to Diameter, RADIUS has no mandatory encryption support. Sending H(A1) in the clear can make some attacks easier. Here's the compromise: A new attribute Digest-HA1 is introduced. It's use is restricted to *-sess algorithms, where HA1 is constructed partially from random values. From the text: o If the Digest-QoP attribute's value is 'auth' or unspecified, the RADIUS server puts a Digest-Response-Auth attribute into the Access-Accept message o If the Digest-QoP attribute's value is 'auth-int' and the Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess', the RADIUS server puts a Digest-HA1 attribute into the Access-Accept message. o If the Digest-QoP attribute's value is 'auth-int' and the Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the RADIUS server MUST NOT send a Digest-HA1 attribute unless the connection between RADIUS server and client is encrypted or otherwise protected against eavesdropping. Issue 9: On suggestion of Avi Lior, I replaced the special Access-Accept with Access-Challenge (Issue 10 refers to NAIbis) Issue 11: 1) missing reference new text: 'Due to the limitations and weaknesses of Digest authentication (see [RFC2617], section 4 />)..' 2) when to use server generated nonces added a paragraph in the overview section Wolfgang From lhadolfunho@ig.com.br Fri Oct 22 15:15:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01107 for ; Fri, 22 Oct 2004 15:15:59 -0400 (EDT) Message-Id: <200410221915.PAA01107@ietf.org> Received: from [66.191.224.127] (helo=66.191.224.127) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CL55z-0004fo-E4 for aaa-archive@ietf.org; Fri, 22 Oct 2004 15:29:18 -0400 Received: from mail.adult-hosting.com (mail.adult-hosting.com [64.185.227.6]) by relay.global.net.pg with SMTP; out, 22 2004 15:07:28 +0700 From: kqbd chris To: aaa-archive@ietf.org Subject: Re: dvoav Sender: kqbd chris Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 22 Oct 2004 16:15:41 -0200 X-Mailer: Microsoft Outlook Build 10.0.2627 X-Priority: 1 X-Spam-Score: 24.5 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Nova pagina 1

urjahsckcurvherha O que você sempre procuro esta aqui
Empresario europeu procura pessoas para oportunidade de negocio 9463978
parcial R$1000 – R$3000 814
integral  ate R$7000 euohdv
clique aqui
feouenraadbty
para retirar seu e-mail clique aqui.


dhttelt http://rqb.com.br   http://pwgj.com.br   http://vjtbeh.com.br   http://pwulbga.com.br   http://itjq.com.br   http://gig.com.br   http://joixxmd.com.br   http://ruqneek.com.br   http://dico.com.br   http://cgywpb.com.br   http://iywmvm.com.br   http://ckdy.com.br   http://lvbbrjc.com.br   http://meljup.com.br   http://yhvd.com.br   http://dfm.com.br   http://towa.com.br   http://fcdwae.com.br  

http://terra.com.br http://uol.com.br http://msn.co.il http://msn.com http://msn.com.br http://hotmail.com http://superig.com.br http://hotmail.co.il http://hotmail.co.uk http://ig.com.br

 xekkpcaryldhbsodhdnqcfvqxvfuoiuxf From owner-aaa-wg@merit.edu Mon Oct 25 07:28:46 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15946 for ; Mon, 25 Oct 2004 07:28:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2420391209; Mon, 25 Oct 2004 07:28:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1D6691212; Mon, 25 Oct 2004 07:28:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A3D191209 for ; Mon, 25 Oct 2004 07:28:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 571ADB21B0; Mon, 25 Oct 2004 07:28:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 55E8FB2087 for ; Mon, 25 Oct 2004 07:28:36 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PBSYt17887 for ; Mon, 25 Oct 2004 14:28:35 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 14:23:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9PBNshq005593 for ; Mon, 25 Oct 2004 14:23:54 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 001a3V4j; Mon, 25 Oct 2004 14:23:51 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PBNkS21521 for ; Mon, 25 Oct 2004 14:23:46 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 14:23:32 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 14:23:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Re: AAA URI draft Date: Mon, 25 Oct 2004 14:23:30 +0300 Message-ID: <78577AECEB6226409F9F4BFB53FE183708F792@esebe054.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: AAA URI draft Thread-Index: AcS3Pd7wiyDg9sm8Q0e8GW3jDdOXWgDRclxg From: To: X-OriginalArrivalTime: 25 Oct 2004 11:23:30.0946 (UTC) FILETIME=[0E793E20:01C4BA85] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > - Make the aaa/aaas URI schemes protocol agnostic; remove all the=20 > parameters (including protocol and transport). I think we should keep aaa and aaas schemes including the parameters. > - Define diameter and diameters URI schemes. Make them protocol=20 > specific, obviously. Add a parameter that specifies the transport. I'm not sure if we need Diameter-specific uri-schemes, but if=20 such schemes are defined I'd suggest shorter forms 'dia:' and 'dias:' :) BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Miguel Garcia > Sent: 21 October, 2004 10:03 > To: Rui Carmo > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Re: AAA URI draft >=20 >=20 > Rui: >=20 > I am not the advocate of any proposal, but I will give you my=20 > opinion on=20 > this. >=20 > 1) The aaa URI scheme is already specified in RFC 3588 (though not=20 > registered with IANA). Although I personally don't like URIs that are=20 > not protocol specific, this is a common practice today. Think of the=20 > mailto, im and pres URI schemes for e-mail, instant messaging and=20 > pressence, respectively. All of them are protocol independent. >=20 > 2) As far as I know, it is not feasible to expose the combination of=20 > protocol/transport/security in the URI scheme itself, because the=20 > combination will be growing with time and makes unfeasible to have a=20 > future compatible deployment of Diameter. As far as I know,=20 > the IESG has=20 > typically allowed to differentiate the security requirements=20 > in the URI,=20 > but not other aspects such as the transport protocol. For=20 > instance, http=20 > and https URIs differentiate the security aspects of HTTP. Well, HTTP=20 > runs over TCP so it is not a big issue. But take as an=20 > example the sip=20 > URI scheme. SIP can run over TCP, UDP, and SCTP. There are not such=20 > thing as sip.tcp, sip.udp, sip.sctp, sips.tcp, sips.sctp URI schemes.=20 > Instead, there are only sip and sips URI schemes. >=20 > Therefore my opinion is that we shouldn't go in a direction where the=20 > transport protocol is visible in the URI scheme. I think we=20 > should try=20 > to keep the aaa and aaas URI schemes. >=20 > 3) Having said that, I agree with Roy that the combinations=20 > of different=20 > AAA protocols, transport protocols and security protocols looks a bit=20 > complicated. I wonder if we could make things easier by defining a=20 > diameter and diameters URI schemes. If we go in this=20 > direction I think=20 > we would have to do the following: > - Make the aaa/aaas URI schemes protocol agnostic; remove all the=20 > parameters (including protocol and transport). > - Define diameter and diameters URI schemes. Make them protocol=20 > specific, obviously. Add a parameter that specifies the transport. > - Somebody (we could do it if assigned) should do similar thing with=20 > radius URI scheme. > - We should define guidelines or even procedures to translate between=20 > aaa/aaas URI schemes and their corresponding diameter/radius=20 > URI schemes. >=20 > Comments? >=20 > BR, >=20 > Miguel >=20 > Rui Carmo wrote: > >=20 > > On Sep 10, 2004, at 11:28 PM, Roy T. Fielding wrote: > >=20 > >> but as near as I can tell, the only resources ever=20 > provided by those > >> protocols are the service points (i.e., the fact that=20 > there is an AAA > >> listener at that address). Why, then, is there a desire=20 > for a grab-bag > >> identification scheme like "aaa", which hides the most=20 > important bits > >> of information at the end of the URI, when the same thing can be > >> better accomplished by specific URI schemes for each service? > >> > >> In other words, what I would propose is the following: > >> > >> d =3D "diameter" "://" authority ; Diameter/sctp > >> d-tcp =3D "diameter.tcp" "://" authority ; Diameter/tcp > >> d-tls =3D "diameter.tls" "://" authority ;=20 > Diameter/tls/sctp > >> dtc =3D "diameter.tls.tcp" "://" authority ;=20 > Diameter/tls/tcp > >> > >> r =3D "radius" "://" authority ; RADIUS/udp > >> > >> t =3D "tacacs" "://" authority ; TACACS+/sctp > >> t-udp =3D "tacacs.udp" "://" authority ; TACACS+/udp > >> > >> Note that the above removes all of the complexity described in > >> section 3 regarding the various combinations of AAA protocol, > >> transport, and session-based security that are not allowed. If you > >> simply define the URI schemes such that illegitimate combinations > >> aren't even an option, then you don't have to require that > >> applications keep track of what combination of parameters > >> are allowed. Likewise, all of the aliases (multiple URIs for the > >> same service) are removed by specifying that the short scheme > >> defines the most common protocol case (just as the "http" scheme > >> defines HTTP over TCP, not HTTP over any transport). > >=20 > >=20 > > I like it. It is consistent with the need to manage=20 > different sorts of=20 > > AAA servers during the migration to Diameter and can cater=20 > for all the=20 > > usual O&M issues (like custom port numbers, defaults, etc.) in a=20 > > non-ambiguous way that will minimize the chances for human error. > >=20 > >> Furthermore, if we later discover that there are more resources > >> hidden within the Diameter, TACACS+, and RADIUS servers beyond > >> the mere existence of the service points, then all we need to > >> do is add a path to the URI definition and those new services > >> can be used by other information systems beyond AAA. > >=20 > >=20 > > Yes, and applications handling the URI, as you put it quite=20 > nicely, can=20 > > process it in a standard way (with the proper validations, I can=20 > > envision using the URI as an XPath into a XML configuration=20 > file, etc.). > >=20 > > Rui Carmo > >=20 > >=20 >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland >=20 From admin@staffadministrator.com Thu Oct 28 03:02:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11572; Thu, 28 Oct 2004 03:02:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN4X1-0001ZM-UF; Thu, 28 Oct 2004 03:17:18 -0400 Received: from 24-205-69-162.pas-eres.charterpipeline.net ([24.205.69.162]) by mx2.foretec.com with smtp (Exim 4.24) id 1CN4Iz-000088-Aa; Thu, 28 Oct 2004 03:02:41 -0400 Received: from [158.45.39.138] by 24-205-69-162.pas-eres.charterpipeline.net; Thu, 28 Oct 2004 12:00:06 +0400 Message-ID: From: "Administrator" To: subip-area@ietf.org Subject: ADV: Staff Announcement Date: Thu, 28 Oct 04 12:00:06 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="503B601_..15." X-Spam-Score: 22.3 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --503B601_..15. Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members, Staff and Associates: You Must Respond By 5 P.M. Friday, October 29, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Friday, October 29, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Friday, October 29, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Friday, October 29, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Friday, October 29, 2004 Visit our website at http://www.avtechdirect-nonprofits.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --503B601_..15.-- From owner-aaa-wg@merit.edu Sat Oct 30 04:42:24 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08741 for ; Sat, 30 Oct 2004 04:42:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8275691201; Sat, 30 Oct 2004 04:42:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 521E791208; Sat, 30 Oct 2004 04:42:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0534391201 for ; Sat, 30 Oct 2004 04:42:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0EB6B21E5; Sat, 30 Oct 2004 04:42:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by segue.merit.edu (Postfix) with ESMTP id 2C8B4B242E for ; Sat, 30 Oct 2004 04:42:14 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 30 Oct 2004 10:42:07 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BE5C.0CC01531" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: [AAA-WG]: [AAA] Using DIAMETER_MISSING_AVP for optional AVP Date: Sat, 30 Oct 2004 10:39:48 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026018600E9@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA] Using DIAMETER_MISSING_AVP for optional AVP Thread-Index: AcS+XAG9uru3HxFeR+iNpPqzk9TTHQ== From: "MORAND Lionel RD-CORE-ISS" To: X-OriginalArrivalTime: 30 Oct 2004 08:42:07.0076 (UTC) FILETIME=[5680B240:01C4BE5C] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BE5C.0CC01531 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi AAA folks, In the RFC 3588, the result-code DIAMETER_MISSING_AVP is ussed to indicate that a mandatory AVP (required by the command code ABNF specification) is missing in the received command. Is it possible to use the DIAMETER_MISSING_AVP result code along with the Failed-AVP AVP to indicate that an optional AVP (from the ABNF point of view) is missing in the received command? If not, could you identify some operational issues? Any opinion? Lionel ------_=_NextPart_001_01C4BE5C.0CC01531 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi = AAA=20 folks,

In the RFC=20 3588, the result-code DIAMETER_MISSING_AVP is ussed to indicate that a = mandatory=20 AVP (required by the command code ABNF specification) is missing in the = received=20 command.

Is=20 it possible to use the DIAMETER_MISSING_AVP result code along with the=20 Failed-AVP AVP to indicate that an optional AVP (from the ABNF point of = view) is=20 missing in the received command? If not, could you identify=20 some operational issues?

Any=20 opinion?

Lionel

------_=_NextPart_001_01C4BE5C.0CC01531--