From owner-aaa-wg@merit.edu Sun Dec 1 21:46:05 2002 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 VAA21005 for ; Sun, 1 Dec 2002 21:46:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE1389124C; Sun, 1 Dec 2002 21:48:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A18D09124D; Sun, 1 Dec 2002 21:48:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58A699124C for ; Sun, 1 Dec 2002 21:48:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E1435DDF9; Sun, 1 Dec 2002 21:48:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 56A1B5DDB3 for ; Sun, 1 Dec 2002 21:48:40 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB22m2908342 for ; Mon, 2 Dec 2002 04:48:02 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 04:48:38 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 04:48:37 +0200 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 2 Dec 2002 10:48:26 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter Base Application ID values Date: Mon, 2 Dec 2002 10:48:23 +0800 Message-ID: Thread-Topic: [AAA-WG]: Diameter Base Application ID values Thread-Index: AcKX/85eB0n3xzOfTPuiumJH4c/YoAAMTX3wAF2ko3A= From: To: , Cc: , X-OriginalArrivalTime: 02 Dec 2002 02:48:26.0573 (UTC) FILETIME=[49C367D0:01C299AD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The current application ID allocation would make the following scenario impossible, since it assumes all accounting information be handled in one accounting server: Access Router | /------- Diameter Relay -------\ | | | NASREQ Authentication Multimedia ACCT server Server ACCT server However, such a scenario could be realistic in the future that different service vendors have their own accounting servers. Then, shall we differentiate the accounting regards to different services? For example (assuming the last bit of Application-ID as the bit of AUTH/ACCT ): Base Common 0 Base Accounting 1 /* All accounting information */ NASREQ 2 [NASREQ] NASREQ Accounting 3 [NASREQ] Mobile-IP 4 [DIAMMIP] Mobile-IP Accounting 5 [DIAMMIP] Relay 0xffffffff Best regards, roger -----Original Message----- From: ext [mailto:john.loughney@nokia.com] Sent: Saturday, November 30, 2002 1:27 PM To: yohba@tari.toshiba.com Cc: aboba@internaut.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter Base Application ID values Hi Yoshihiro, > On Thu, Nov 28, 2002 at 03:07:21PM +0200, > john.loughney@nokia.com wrote: > > Hi all, > > > > Currently, we have the application IDs as follows in the > Diameter base spec: > > > > NASREQ 1 [NASREQ] > > Mobile-IP 4 [DIAMMIP] > > Diameter Base Accounting 5 > > Relay 0xffffffff > > > > Would anyone complain if they were modified to: > > > > Diameter Base Accounting 0 > > NASREQ 1 [NASREQ] > > Mobile-IP 2 [DIAMMIP] > > Relay 0xffffffff > > I have one question. > > Which Application ID value should be included in Diameter headers > for messages that are common to all applications but not ACR/ACA? > For example, my implementation is using 0 for CER/CEA. Actually, I was thinking the same thing. So we would have: Common 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Base Accounting 3 Relay 0xffffffff John From owner-aaa-wg@merit.edu Mon Dec 2 01:22:49 2002 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 BAA25683 for ; Mon, 2 Dec 2002 01:22:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E53E391229; Mon, 2 Dec 2002 01:25:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B30429124F; Mon, 2 Dec 2002 01:25:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A34291229 for ; Mon, 2 Dec 2002 01:25:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 621AE5DFBC; Mon, 2 Dec 2002 01:25:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id A8EBB5DE02 for ; Mon, 2 Dec 2002 01:25:22 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB26QS612896 for ; Mon, 2 Dec 2002 08:26:28 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 08:25:21 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 08:25:21 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 08:25:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter Base Application ID values Date: Mon, 2 Dec 2002 08:25:20 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diameter Base Application ID values Thread-Index: AcKX/85eB0n3xzOfTPuiumJH4c/YoAAMTX3wAF2ko3AACPdFEA== From: To: , Cc: , X-OriginalArrivalTime: 02 Dec 2002 06:25:20.0949 (UTC) FILETIME=[96EF9650:01C299CB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Roger, Thanks for the input. Perhaps it would be best if the authors of the MIP doc and the NASREQ doc comment on this. Is this potentially useful for those applications? It may simplify the routing of the messages, but we need to see if it is useful for the applications as well. thanks, John > -----Original Message----- > From: Liu Qing.Roger (Nokia-RD/Beijing) > Sent: 02 December, 2002 04:48 > To: Loughney John (NRC/Helsinki); yohba@tari.toshiba.com > Cc: aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter Base Application ID values > > > Hi, > > The current application ID allocation would make the > following scenario impossible, since it assumes all > accounting information be handled in one accounting server: > > Access Router > | > /------- Diameter Relay -------\ > | | | > NASREQ Authentication Multimedia > ACCT server Server ACCT server > > However, such a scenario could be realistic in the future > that different service vendors have their own accounting servers. > > Then, shall we differentiate the accounting regards to > different services? For example (assuming the last bit of > Application-ID as the bit of AUTH/ACCT ): > Base Common 0 > Base Accounting 1 /* All accounting information */ > NASREQ 2 [NASREQ] > NASREQ Accounting 3 [NASREQ] > Mobile-IP 4 [DIAMMIP] > Mobile-IP Accounting 5 [DIAMMIP] > Relay 0xffffffff > > Best regards, > roger > > > > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: Saturday, November 30, 2002 1:27 PM > To: yohba@tari.toshiba.com > Cc: aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter Base Application ID values > > > Hi Yoshihiro, > > > On Thu, Nov 28, 2002 at 03:07:21PM +0200, > > john.loughney@nokia.com wrote: > > > Hi all, > > > > > > Currently, we have the application IDs as follows in the > > Diameter base spec: > > > > > > NASREQ 1 [NASREQ] > > > Mobile-IP 4 [DIAMMIP] > > > Diameter Base Accounting 5 > > > Relay 0xffffffff > > > > > > Would anyone complain if they were modified to: > > > > > > Diameter Base Accounting 0 > > > NASREQ 1 [NASREQ] > > > Mobile-IP 2 [DIAMMIP] > > > Relay 0xffffffff > > > > I have one question. > > > > Which Application ID value should be included in Diameter headers > > for messages that are common to all applications but not ACR/ACA? > > For example, my implementation is using 0 for CER/CEA. > > Actually, I was thinking the same thing. So we would have: > > Common 0 > NASREQ 1 [NASREQ] > Mobile-IP 2 [DIAMMIP] > Base Accounting 3 > Relay 0xffffffff > > John > From owner-aaa-wg@merit.edu Mon Dec 2 04:13:52 2002 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 EAA08434 for ; Mon, 2 Dec 2002 04:13:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 071399121C; Mon, 2 Dec 2002 04:16:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD0399122B; Mon, 2 Dec 2002 04:16:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36CF39121C for ; Mon, 2 Dec 2002 04:16:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1EBCA5DE81; Mon, 2 Dec 2002 04:16:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 6195C5DDA3 for ; Mon, 2 Dec 2002 04:15:59 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB29H5606801 for ; Mon, 2 Dec 2002 11:17:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 11:15:56 +0200 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 11:15:56 +0200 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 17:15:34 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter Base Application ID values Date: Mon, 2 Dec 2002 17:12:56 +0800 Message-ID: Thread-Topic: [AAA-WG]: Diameter Base Application ID values Thread-Index: AcKZ4Led7Yzi0LHLRDyxlETmMmEp/gAAQGKQ From: To: , , Cc: , X-OriginalArrivalTime: 02 Dec 2002 09:15:34.0759 (UTC) FILETIME=[5ED74F70:01C299E3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fredrik, Application ID is used in capacity negotiation first. The current Application ID allocation would make the capacity negotiation between accounting servers and the diameter relay unclear: Access Router | /------- Diameter Relay -------\ | | | NASREQ Authentication Multimedia ACCT server Server ACCT server Best regards, roger -----Original Message----- From: ext Fredrik Johansson [mailto:frej@ipunplugged.com] Sent: Monday, December 02, 2002 4:51 PM To: Loughney John (NRC/Helsinki); Liu Qing.Roger (Nokia-RD/Beijing); yohba@tari.toshiba.com Cc: aboba@internaut.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter Base Application ID values Isn't it enough to indicate that the application is MIP or NASREQ and then you can route based on command code, e.g. mip accounting to one server and MIP authentication to another. /fredrik -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of john.loughney@nokia.com Sent: den 2 december 2002 07:25 To: qing.roger.liu@nokia.com; yohba@tari.toshiba.com Cc: aboba@internaut.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter Base Application ID values Hi Roger, Thanks for the input. Perhaps it would be best if the authors of the MIP doc and the NASREQ doc comment on this. Is this potentially useful for those applications? It may simplify the routing of the messages, but we need to see if it is useful for the applications as well. thanks, John > -----Original Message----- > From: Liu Qing.Roger (Nokia-RD/Beijing) > Sent: 02 December, 2002 04:48 > To: Loughney John (NRC/Helsinki); yohba@tari.toshiba.com > Cc: aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter Base Application ID values > > > Hi, > > The current application ID allocation would make the > following scenario impossible, since it assumes all > accounting information be handled in one accounting server: > > Access Router > | > /------- Diameter Relay -------\ > | | | > NASREQ Authentication Multimedia > ACCT server Server ACCT server > > However, such a scenario could be realistic in the future > that different service vendors have their own accounting servers. > > Then, shall we differentiate the accounting regards to > different services? For example (assuming the last bit of > Application-ID as the bit of AUTH/ACCT ): > Base Common 0 > Base Accounting 1 /* All accounting information */ > NASREQ 2 [NASREQ] > NASREQ Accounting 3 [NASREQ] > Mobile-IP 4 [DIAMMIP] > Mobile-IP Accounting 5 [DIAMMIP] > Relay 0xffffffff > > Best regards, > roger > > > > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: Saturday, November 30, 2002 1:27 PM > To: yohba@tari.toshiba.com > Cc: aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter Base Application ID values > > > Hi Yoshihiro, > > > On Thu, Nov 28, 2002 at 03:07:21PM +0200, > > john.loughney@nokia.com wrote: > > > Hi all, > > > > > > Currently, we have the application IDs as follows in the > > Diameter base spec: > > > > > > NASREQ 1 [NASREQ] > > > Mobile-IP 4 [DIAMMIP] > > > Diameter Base Accounting 5 > > > Relay 0xffffffff > > > > > > Would anyone complain if they were modified to: > > > > > > Diameter Base Accounting 0 > > > NASREQ 1 [NASREQ] > > > Mobile-IP 2 [DIAMMIP] > > > Relay 0xffffffff > > > > I have one question. > > > > Which Application ID value should be included in Diameter headers > > for messages that are common to all applications but not ACR/ACA? > > For example, my implementation is using 0 for CER/CEA. > > Actually, I was thinking the same thing. So we would have: > > Common 0 > NASREQ 1 [NASREQ] > Mobile-IP 2 [DIAMMIP] > Base Accounting 3 > Relay 0xffffffff > > John > From owner-aaa-wg@merit.edu Mon Dec 2 13:30:36 2002 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 NAA01224 for ; Mon, 2 Dec 2002 13:30:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1FB5391269; Mon, 2 Dec 2002 13:31:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F4A791268; Mon, 2 Dec 2002 13:31:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F45291267 for ; Mon, 2 Dec 2002 13:31:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4438C5DDDE; Mon, 2 Dec 2002 13:31:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 56C8A5DDCD for ; Mon, 2 Dec 2002 13:31:21 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2IWRW05232 for ; Mon, 2 Dec 2002 20:32:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 20:30:44 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 20:30:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 20:30:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 388: Diameter Peer Discovery and Authorization Date: Mon, 2 Dec 2002 20:30:43 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 388: Diameter Peer Discovery and Authorization Thread-Index: AcKP8iXgPIL86uHiR0aPtvogUOpqXwKPsO2A From: To: , X-OriginalArrivalTime: 02 Dec 2002 18:30:44.0361 (UTC) FILETIME=[ECE93790:01C29A30] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA01224 Done. > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 19 November, 2002 18:31 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 388: Diameter Peer Discovery and > Authorization > > > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: November 11, 2002 > Reference: > Document: BASE-15 > Comment type: T > Priority: S > Section: 5.2 > Rationale/Explanation of issue: > > While Diameter uses IPsec or TLS for transmission layer > security, the ability authenticate with IKE or TLS does > not imply authorization. > > Therefore, with pre-shared key authentication in IKE it > is still typically necessary to manually configure the > IP address of the NAS or AAA server, along with the > corresponding pre-shared key. With certificate > authentication, the FQDN is typically manually > configued, along with the trusted root. > > This means that Diameter Peer discovery, even if > secured, must be careful to make sure that the > discovered Diameter peers are actually authorized > for their roles. This is particularly important > when DNS is used for discovery, because the > use of DNSSEC does not imply authorization. > For example, a host could exist that had a TyLS > certificate (for web use), and secured DNS > RRs, but was *not* authorized to act as a Diameter > server. > > Similarly, with SLPv2, security SHOULD be used, > both to validate the integrity of the advertisements > as well as to determine authorization to act as a > Diameter Peer. > > Change: > > "It is recommended that SLPv2 security > be deployed (this requires distributing keys to SLPv2 agents). > This is discussed further in Appendix A." > > To: > > "SLPv2 security SHOULD be used (requiring distribution of > keys to SLPv2 agents) in order to ensure that discovered > peers are authorized for their roles. SLPv2 is discussed > further in Appendix A." > > Change: > > "If the server is using a site certificate, the domain name in > the query and the domain name in the replacement field MUST > both be valid based on the site certificate handed out by the > server in the TLS exchange. Similarly, the domain name in the > SRV query and the domain name in the target in the SRV record > MUST both be valid based on the same site certificate. > Otherwise, an attacker could modify the DNS records to contain > replacement values in a different domain, and the client could > not validate that this was the desired behavior, or the result > of an attack." > > To: > > "If the server is using a site certificate, the domain name in > the query and the domain name in the replacement field MUST > both be valid based onthe the site certificate handed out by the > server in the TLS or IKE exchange. Similarly, the domain name in the > SRV query and the domain name in the target in the SRV record > MUST both be valid based on the same site certificate. > Otherwise, an attacker could modify the DNS records to contain > replacement values in a different domain, and the client could > not validate that this was the desired behavior, or the result > of an attack. > > Also, the Diameter Peer MUST check to make sure that the discovered > peers are authorized to act in its role. Authentication via IKE > or TLS, or validation of DNS RRs via DNSSEC is not sufficient > to conclude this. For example, a web server may have obtained a > valid TLS certificate, and secured RRs may be included in the > DNS, but this does not imply that it is authorized to act as > a Diameter Server. > > Authorization can be achieved for example, by configuration of a > Diameter Server CA. Alternatively this can be achieved by > definition of OIDs within TLS or IKE certificates so as to > signify Diameter Server authorization." > > > From owner-aaa-wg@merit.edu Mon Dec 2 13:47:03 2002 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 NAA02528 for ; Mon, 2 Dec 2002 13:47:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 052C291272; Mon, 2 Dec 2002 13:48:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40E4191268; Mon, 2 Dec 2002 13:45:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D85A291267 for ; Mon, 2 Dec 2002 13:45:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id E202B5DDD2; Mon, 2 Dec 2002 13:45:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B97475DDE2 for ; Mon, 2 Dec 2002 13:45:32 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2IkcW10465 for ; Mon, 2 Dec 2002 20:46:38 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 2 Dec 2002 20:45:31 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 20:45:31 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 20:45:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: FW: Diameter Base issue: DIAMETER_NO_COMMON_SECURITY error code not defined Date: Mon, 2 Dec 2002 20:45:30 +0200 Message-ID: Thread-Topic: Diameter Base issue: DIAMETER_NO_COMMON_SECURITY error code not defined Thread-Index: AcKPJL2EBw1wy/rQEdatbQAGKbPKfALDdW9w From: To: Cc: X-OriginalArrivalTime: 02 Dec 2002 18:45:31.0376 (UTC) FILETIME=[FD9CF700:01C29A32] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02528 I have added the following text: DIAMETER_NO_COMMON_SECURITY 5017 This error is returned when a CER message is received, and there are no common security models supported between the peers. A Capabilities-Exchange-Answer (CEA) MUST be returned with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY. And added the message to the IANA Consideration section. John -----Original Message----- From: Benak Otilia (NET/Helsinki) Sent: 18 November, 2002 19:06 To: Loughney John (NRC/Helsinki) Subject: Diameter Base issue: DIAMETER_NO_COMMON_SECURITY error code not defined Hi, I started writing this as an issue, but since I don't know what the procedure is now when the Diameter base protocol draft is under IESG approval process, I am sending the information directly to you. Br, Otilia Submitter name: Otilia Benak Submitter email address: otilia_benak@yahoo.com Date first submitted: 18.11.02 Reference: Document: base Comment type: E Priority: S Section: 7 Rationale/Explanation of issue: Section 5.3 states "a receiver of a Capabilities-Exchange-Req (CER) message that does not have any security model in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY", but the value of DIAMETER_NO_COMMON_SECURITY is not defined. Requested change: Define DIAMETER_NO_COMMON_SECURITY in section 7. From owner-aaa-wg@merit.edu Mon Dec 2 13:47:18 2002 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 NAA02558 for ; Mon, 2 Dec 2002 13:47:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 246C89126E; Mon, 2 Dec 2002 13:48:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E21789126D; Mon, 2 Dec 2002 13:48:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2819191275 for ; Mon, 2 Dec 2002 13:47:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 10A6F5DDA4; Mon, 2 Dec 2002 13:47:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 2295E5DDDE for ; Mon, 2 Dec 2002 13:47:32 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2ImbW11267 for ; Mon, 2 Dec 2002 20:48:37 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 20:47:31 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 20:47:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 20:47:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Late comments (fwd) Date: Mon, 2 Dec 2002 20:47:29 +0200 Message-ID: Thread-Topic: [AAA-WG]: Late comments (fwd) Thread-Index: AcKOTM3RPHnhfWI2RQKCNuZBl+OCUAL5lzTA From: To: , X-OriginalArrivalTime: 02 Dec 2002 18:47:30.0540 (UTC) FILETIME=[44A3F2C0:01C29A33] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02558 Hi all, I think that the best approach would be to work with IANA on this to kickstart the registry, rather than try to capture everything in the current IANA considerations section. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 17 November, 2002 16:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Late comments > (fwd) > > > > ------- start of forwarded message ------- > From: "IANA" > To: "Randy Bush" > Cc: "IESG" > Subject: Late comments > Date: Thu, 14 Nov 2002 07:48:55 -0800 > > > Token: Bush, Randy > > Hi Randy, > > I'm getting this comment to you a little > late. This document was late night reading > for me last night. > > This stuff is a bit confusing. I was wondering > if it would be possible for the authors to > include an initial registry in this document? > > This would help the IANA when it comes time > to take care of the IANA actions. If that > is not possible can one of the authors assist > me in getting this registry set-up? > > Suggestions? > > Thanks, > > Michelle > IANA > ------- end of forwarded message ------- > > > From owner-aaa-wg@merit.edu Mon Dec 2 14:30:49 2002 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 OAA05633 for ; Mon, 2 Dec 2002 14:30:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 669BB9126C; Mon, 2 Dec 2002 14:33:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3449D9126F; Mon, 2 Dec 2002 14:33:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6790D9126C for ; Mon, 2 Dec 2002 14:32:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 420625E01D; Mon, 2 Dec 2002 14:32:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 87DF35E01A for ; Mon, 2 Dec 2002 14:32:41 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2JXlW00078 for ; Mon, 2 Dec 2002 21:33:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 21:31:02 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 21:31:03 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 21:31:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: [aaa-editors] Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard (fwd) Date: Mon, 2 Dec 2002 21:31:02 +0200 Message-ID: Thread-Topic: [aaa-editors] Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard (fwd) Thread-Index: AcKJm/q7b5NlxUs5R/ebI0vu6t3ElgQl8dYQ From: To: , X-OriginalArrivalTime: 02 Dec 2002 19:31:02.0940 (UTC) FILETIME=[59C08DC0:01C29A39] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA05633 Hi, > - I see (on page 11 and page 19) 3 different terms for the > same thing (or are they indeed meant to be different?). To > me it seems these all refer to the DIAMMIP document/application. > They use: > - Mobile IPv4 > - MIPv4 > - Mobile IP Fixed. > - Is there an explanation as to how the allocations were done > in sect 2.4 ??? why junp from 1 to 4 and 5 and then to the end? Fixed. > - I think SMB already mentioned it, but there are quiet a few > places where one should use example.net or example.com > instead of abc.com and mno.net Fixed > - Last sentence of sect 2.9. I think they mean RECOMMENDED > instead of recommended Fixed > - Sect 3 > - In the diagram they use "Ver", in the legend below it they > use "Version" Fixed > - In the diagram they use "RPETrrrr" in the legend below they > use "Command Flags" Fixed. > - I find the use of the T-flag pretty complicated. I tried to make it more simple & move details to appendix c. > - they specify that the reserved bits MUST be zero on sending > and that they cause an error upon receipt. I think that normally > I see that such reserved bits are ignored on receipt. If this > is intentionally, then I guess it is OK. I just wondered. That makes sense. > - They claim that the version field MUST be 1. I guess that it > must contain a valid version, and that at the time of this writing > there is only version 1. Well, as the there is only version 1, it must be 1. Future versions of this document will update this, if necessary. > - They talk about "Origin-Host" in the description of End-to-End > Identifier... but at that point I have no idea yet what "Origin-Host" > is supposed to be. I put a reference in. > - Last para of sect 4. > "Zero bytes are added..." > Mmm... I guess that "A number of zero-valued bytes are added" > Maybe it is just me with my poor undestanding of English? Nope, your understanding of English is perfect in this case. > - Sect 4.1 and sect 4.2 > - First, I would remove the number 4.2 or otherwise renumber it to > 4.1.1 It is still part of the AVP header. fixed. > - But... more importantly: > I get confused here w.r.t. the value of zero (0) for Vendor-ID. > It is not clear to me if value of zero is used ever or that instead > one always leaves out the optional Vendor-ID field if the value is > supposed to be zero. > If the latter, are they saying that the field Vendor-ID SHOULD NEVER > contain a value of zero.... > As I said, I find it confusing > By the way, vendor IDs (the SMI values they are using here) cannot be > zero, cause the value zero is RESERVED, see > http://www.iana.org/assignments/enterprise-numbers Agreed & fixed. > - It would be an improvement I think if they actually mentioned that > they are indeed the Enterprise-Numbers as registered by IANA > (At least that is what I understood they are meant to be). It will > make it easier to find them. the IANA resgistry does not talk about > Vendor-ID. It is actually mentioned under Vendor-ID section. > - Bullet 1) on page 37 talks about "base Diameter standard". Is that > appropriate? Should it be "base Diameter protocol" ?? Yup. > - top of page 38 talks about "standard AVP". Is that appropriate? > If it is another application specific AVP, it may be a vendor specific > one and so may not be a standard AVP ?? It means that an AVP that has been standardized in the IETF, not a vendor specific AVP. > - Section 4.4 > I wonder if the use of IPAddress as a datatype may not be misleading. > MANY MANY people know this as a SNMP/SMI datatype to represent an > IPv4 address. And so I immediatly jumped up and though: what about IPv6. > Turns out that they use this datatype for both IPv4 and IPv6. And one > has to figure it out based on the length. > Mmmm... is this smart? I know that we have abandoned all that in the > SMI world, and we use a discriminated union instead namely an > InetAddressType and and InetAddress. Discussed in IETF55, as a way to ensure compatibility with RADIUS. More in another mail. John From owner-aaa-wg@merit.edu Mon Dec 2 14:46:30 2002 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 OAA06525 for ; Mon, 2 Dec 2002 14:46:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 95DC19127D; Mon, 2 Dec 2002 14:48:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 631D49127C; Mon, 2 Dec 2002 14:48:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78CC991276 for ; Mon, 2 Dec 2002 14:48:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EB4E5E021; Mon, 2 Dec 2002 14:48:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 875305DDCD for ; Mon, 2 Dec 2002 14:48:16 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2JlcG09657 for ; Mon, 2 Dec 2002 21:47:38 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 21:48:15 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 21:48:14 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 21:48:13 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 21:48:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Diameter Base: Origin-Host and Origin-Realm the same in 5.4.1, 5.4.2, 5.5.1, 5.5.2 ??? Date: Mon, 2 Dec 2002 21:48:12 +0200 Message-ID: Thread-Topic: [aaa-editors] Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard (fwd) Thread-Index: AcKJm/q7b5NlxUs5R/ebI0vu6t3ElgQn1jvA From: To: , X-OriginalArrivalTime: 02 Dec 2002 19:48:13.0397 (UTC) FILETIME=[BFF3D050:01C29A3B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA06525 Hi all, Bert asked: > - Sect 5.4.1. and 5.4.2. > Are the Origin-Host and Origin-Realm the same here.?? > I suspect not (from later text in the document), but since the 2nd is an > answer to the first, I first thought they would be the same (or had to be > the same)... you may want to spell it out. > - Same question for 5.5.1 and 5.5.2 and at this late hour, I don't remember - any one remember? John From owner-aaa-wg@merit.edu Mon Dec 2 15:02:59 2002 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 PAA07323 for ; Mon, 2 Dec 2002 15:02:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B134691274; Mon, 2 Dec 2002 15:05:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ACD391276; Mon, 2 Dec 2002 15:05:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68AC591274 for ; Mon, 2 Dec 2002 15:05:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 52C415DF47; Mon, 2 Dec 2002 15:05:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 0924F5DED2 for ; Mon, 2 Dec 2002 15:05:32 -0500 (EST) Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Iwot-0005qk-00; Mon, 02 Dec 2002 12:05:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Iwos-00088v-00; Mon, 02 Dec 2002 12:05:30 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: , Subject: RE: [AAA-WG]: Late comments (fwd) References: Message-Id: Date: Mon, 02 Dec 2002 12:05:30 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I think that the best approach would be to work with IANA > on this to kickstart the registry, rather than try to capture > everything in the current IANA considerations section. YES! i would appreciate anyone who could help me learn how, when i thought i said this last week, i could have been more clear without being directive. randy From owner-aaa-wg@merit.edu Mon Dec 2 15:05:42 2002 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 PAA07463 for ; Mon, 2 Dec 2002 15:05:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF88C91276; Mon, 2 Dec 2002 15:08:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF3FB91277; Mon, 2 Dec 2002 15:08:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86C3E91276 for ; Mon, 2 Dec 2002 15:08:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7739C5DF47; Mon, 2 Dec 2002 15:08:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id BB9175DED2 for ; Mon, 2 Dec 2002 15:08:15 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB2K9LW13427 for ; Mon, 2 Dec 2002 22:09:21 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Dec 2002 22:08:13 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 22:08:13 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 2 Dec 2002 22:08:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Late comments (fwd) Date: Mon, 2 Dec 2002 22:08:12 +0200 Message-ID: Thread-Topic: [AAA-WG]: Late comments (fwd) Thread-Index: AcKaPi+/FK+bdSR1Q/qh6bZqP1hQCQAAD16w From: To: Cc: , X-OriginalArrivalTime: 02 Dec 2002 20:08:13.0108 (UTC) FILETIME=[8B092F40:01C29A3E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA07463 Hi Randy, > > I think that the best approach would be to work with IANA > > on this to kickstart the registry, rather than try to capture > > everything in the current IANA considerations section. > > YES! > > i would appreciate anyone who could help me learn how, when i > thought i said this last week, i could have been more clear without > being directive. Well, I guessed that this would fall to me ... I figure I can go a round or two with IANA and then let them do what they do best. John From owner-aaa-wg@merit.edu Mon Dec 2 15:29:03 2002 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 PAA08416 for ; Mon, 2 Dec 2002 15:29:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 252A791279; Mon, 2 Dec 2002 15:31:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45E8091278; Mon, 2 Dec 2002 15:31:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D60AC91277 for ; Mon, 2 Dec 2002 15:31:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id A914D5E021; Mon, 2 Dec 2002 15:31:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1CBE45DFB5 for ; Mon, 2 Dec 2002 15:31:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB2JPZh20168 for ; Mon, 2 Dec 2002 11:25:35 -0800 Date: Mon, 2 Dec 2002 11:25:35 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Minutes from IETF 55 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Can the minute takers from IETF 55 send me their minutes? Apologies if I've lost these. From owner-aaa-wg@merit.edu Mon Dec 2 21:26:05 2002 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 VAA22429 for ; Mon, 2 Dec 2002 21:26:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03FD99127F; Mon, 2 Dec 2002 21:28:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3B9A91280; Mon, 2 Dec 2002 21:28:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A77AE9127F for ; Mon, 2 Dec 2002 21:28:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 957A85DDF9; Mon, 2 Dec 2002 21:28:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from scutsv39.scut.edu.cn (unknown [202.38.193.39]) by segue.merit.edu (Postfix) with ESMTP id 59E8D5DDB3 for ; Mon, 2 Dec 2002 21:28:42 -0500 (EST) Received: from smtp.scut.edu.cn (smtp.scut.edu.cn [202.38.193.66]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id KAA16487; Tue, 3 Dec 2002 10:26:57 +0800 (CST) Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by smtp.scut.edu.cn (8.12.3/8.12.3) with ESMTP id gB32W5AI003794; Tue, 3 Dec 2002 10:32:05 +0800 (CST) Received: from penny-figki2z ([202.38.197.70]) by letterbox.scut.edu.cn (8.12.2/8.12.2) with ESMTP id gB32QeqA007844; Tue, 3 Dec 2002 10:26:56 +0800 (CST) Message-Id: <200212030226.gB32QeqA007844@letterbox.scut.edu.cn> Date: Tue, 3 Dec 2002 10:33:24 +0800 From: Penny To: "charliep@iprg.nokia.com" Cc: "aaa-wg@merit.edu" Subject: [AAA-WG]: About DHCP options with AAA X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA22429 Hi, Charles: I have read your draft draft-perkins-aaav6-05.txt. In section 10 you mention message formats for stateful address autoconfiguration with DHCPv6. You didn't include password option and result option. I wonder whether they are neccessary. I think because AAA authentication needs password to authentication, AAA client needs password of the mobile user. And result option can help DHCP client to know what is the question with its authentication, for example, password invalid, network blocked, etc. Thank you. Penny From owner-aaa-wg@merit.edu Tue Dec 3 00:08:05 2002 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 AAA26703 for ; Tue, 3 Dec 2002 00:08:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 424DE91288; Tue, 3 Dec 2002 00:10:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11D2691289; Tue, 3 Dec 2002 00:10:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C84491288 for ; Tue, 3 Dec 2002 00:10:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 155305DDF9; Tue, 3 Dec 2002 00:10:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9603B5DDCA for ; Tue, 3 Dec 2002 00:10:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB344gP16343 for ; Mon, 2 Dec 2002 20:04:42 -0800 Date: Mon, 2 Dec 2002 20:04:42 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-nasreq-10.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on draft-ietf-aaa-diameter-nasreq-10.txt, which is being considered for advancement as an IETF Proposed Standard: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt AAA WG last call will run until December 28, 2002. Please send comments to the authors or aaa-wg@merit.edu, using the Issues submission template found at: http://www.drizzle.com/~aboba/AAA/issues.html In particular, it is requested that commenters not only identify problems in the draft, but send text to fix the identified issues. Until NASREQ-10 shows up on the IETF archive (should be there soon), it is available for examination on: http://home.attbi.com/~dmitton/draft-ietf-aaa-diameter-nasreq-10.txt From owner-aaa-wg@merit.edu Tue Dec 3 08:20:58 2002 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 IAA18213 for ; Tue, 3 Dec 2002 08:20:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CAF891214; Tue, 3 Dec 2002 08:23:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E8CE91218; Tue, 3 Dec 2002 08:23:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F13CF91214 for ; Tue, 3 Dec 2002 08:23:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id CDBAF5E0B9; Tue, 3 Dec 2002 08:23:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 1E75A5E0B6 for ; Tue, 3 Dec 2002 08:23:31 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3DOcW17751 for ; Tue, 3 Dec 2002 15:24:38 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 15:23:28 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 15:23:29 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 15:23:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: part 3: charset issue with draft-ietf-aaa-diameter-15.txt Date: Tue, 3 Dec 2002 15:23:28 +0200 Message-ID: Thread-Topic: [AAA-WG]: charset issue with draft-ietf-aaa-diameter-15.txt Thread-Index: AcKMG05+8bJ3hET0Qb2BRDsqaWnpwwOIRSDA From: To: , Cc: X-OriginalArrivalTime: 03 Dec 2002 13:23:29.0223 (UTC) FILETIME=[2B202570:01C29ACF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18213 > - Sect 6.1 first couple of paragraphs > What is an implementation supposed to do when a request is not conformant > to all these rules? Send an error I guess. Which error? Section 6.1 is a general section, an overview. I have put in a reference to section 7 for error handling. > - Bullet 4) towards the end of page 70 > and also for example sect 6.1.3 > Must the E-Bit be set? I think section 7.1.3 says that it must. > But I was wondering about that at several places in the text before I > actually got to sect 7.1.3. OK, I have tried to fix that. > - section 6.1.1 > bulleted list.... Are the "should" verbs not very weak? I think I would > write is as follows: > - the Command-Code is set to the appropriate value > - the R-bit is set to 1 > etc... Agreed. > Nits > - Missing an IPR section Added. > - probably first AAA occurence in abstract should be expanded Yup. > - Do we use MUST in an abstract normally Nope. > - Quite a bit of RFC2119 terms is used before it is actually > explained (in sect 1.3) that it is indeed 2119 terms Moved to after the abstract. > - is the frist sentence of the last para of sect 1.2 really a > sentence? It sounds really weird to me. Did some fine tuning. > - sect 1.2.3 acronym EAP used without expanding EAP first used in section 1. and expanded there. > - Acronyms for command-Names used before they are defined > (for example in sect 1.2.4 expanded. > - Last para in sect 1.2.3 is the same as one-but-last para > in sect 1.2.4 (wel more or less) got it. > - Sect 1.4 > Accounting Record is a term they want to define, but in the > definition they seem to be talking about a session record instead? OK fixed. > - Sect 2.1 first sentence: s/profileis/profile is/ OK > - Sect 2.1 1st sentence 4th para > ... an attempt ... SHOULD be .. attempted > Sounds weird to me attempted -> made. > - They are not very consistent in capitalizing things. > For example they use: > - Translation Agent and Translation agent and translation agent > - Redirect agent and redirect agent > - Proxy agent, proxies and Proxies > etc OK, harmonized. > - page 31: > s/referred to as an error messages/referred to as error messages/ ok > - page 31 says "MUST reset this flag"... would it be better to > say "MUST clear this flag" ?? ok > - The "(in network byte order)" seems redudant a number of times > on page 32. All fields in the header are in network byte order > according to the beginning of sect 3. I can live with it. left as is, as it causes no harm. > - page 41/42 > Maybe be more consistent w.r.t. fqdn and FQDN ?? OK, done. > - sect 5.3.3 > Speaks about a "Diameter device". Is that indeed meant? Can a vendor not > just sell a piece of "Diameter software/application" that runs on > someone elses devices, maybe on devices of multiple other vendors? OK, agree. John From owner-aaa-wg@merit.edu Tue Dec 3 08:43:56 2002 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 IAA19334 for ; Tue, 3 Dec 2002 08:43:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8E8F91218; Tue, 3 Dec 2002 08:46:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86B6391296; Tue, 3 Dec 2002 08:46:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F36991218 for ; Tue, 3 Dec 2002 08:46:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECF225DE0C; Tue, 3 Dec 2002 08:46:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 31A5E5DDEB for ; Tue, 3 Dec 2002 08:46:03 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3DlBW05648 for ; Tue, 3 Dec 2002 15:47:11 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 15:46:00 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 15:45:59 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 15:45:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Steve's Comments (RE: Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard) Date: Tue, 3 Dec 2002 15:45:58 +0200 Message-ID: Thread-Topic: Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard Thread-Index: AcKJfuYlkCKcNO3uSHeNMTQaJCVwmgRUQXYQ From: To: Cc: X-OriginalArrivalTime: 03 Dec 2002 13:45:58.0920 (UTC) FILETIME=[4F9B9080:01C29AD2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19334 Hi, Finishing this up. > 3 What purpose is served by the T bit? Given that the underlying > network may be duplicating packets -- a few months ago, I was > seeing up to 90% duplicates on my local loop, with no apparent > ill effects on the stack -- why is there some advantage to > trying to convey that information in Diameter? It almost makes > sense if set only when the application has switched peers before > the retranmission, though it's still not clear to me what > the receiver of such a message would do with the information. It is about application level retransmisions, not network duplicates. > Should the spec indicate that the reserved bits MUST be ignored > by receivers, rather than sending an error? It makes it hard to > start using those bits, given the current language. "Be liberal > in what you receive", etc. Yes, agreed. > 4.1 Same comment about the reserved bits. OK > 4.6 Why is the flag "MAY Encr" when confidentiality is mandatory? > > What is the SHLD NOT column? It's never used in that table. > > I don't see the reasoning for some of the settings of that > flag. For example, I would think that the authentication- and > authorization-related flags would require protection, to guard > against deletion to prevent the operation from taking place, > or to spoof the result. This also illustrates confusion between > the need for integrity protection vs. confidentiality. It > would be good to give some general guidance, for the benefit > of people defining Diameter applications. Any suggestions from the list on this one? > 5.2, search rule 3.2, last paragraph: Unless I'm misreading > something, > it says that the domain suffixes SHOULD and need not match > the original query. Fixed. > 3.3 should probably be numbered 4. > > Discuss DNSsec? What TLS or IPsec certificates should be > checked for? More specifically: the peer discovery mechanisms > MUST be tied to a security authorization model. Each peer to > which a node speaks must be authorized for some role. The > Diameter implementation must have some list of credentials > that are acceptable *for this role*. That point should probably > be discussed here, and possibly in the Security section as well. > (Note that suitable checking in this fashion relegates DNSsec > issues to availability, and not even much of that -- an attacker > can't impersonate a legimate peer, because it lacks the right > credentials.) This is all cleaned up, according to text sent by Bernard. > 5.3 May CER or CEA messages be relayed? No. > 5.3.1 Why is the IP address in the message, when it should be > available via the local incarnation of getpeername()? > > 5.6.4 What is a "hanging octet"? Old reference to Florida 2000 elections & hanging chads ... > 6.1.8 Proxy-Info has security implications, and probably requires an > embedded HMAC with a node-local key. What should be said, something like: Proxy-Info AVP has certain security implications and SHOULD contain an embedded HMAC with a node-local key. Is that sufficient or do we need more detail? > 8.3 The RAA message is curious, and perhaps the answer to my > question is in another AAA document. That said -- in general, > something like a NAS can't do user authentication by itself. > Instead, it's going to use Diameter facilities to send something > upstream. Ultimately, it's the Diameter server that is going to > make the decision. That suggests that reauthenticate is more > of a command from the server to the client, where the server > will, at some point, issue a disconnect message. The current > model seems to suggest a sequence of > > server->client: RAR > client->server: authentication info } repeated > server->client: authentication info } > client->server: success/failure > > In other words, there's a nested exchange. Is that intended? > What Session-ID should be used? Will Diameter implementations > be confused by that sort of sequence? There's a state machine > lurking in the background here, I think. We discussed this at IETF 55 and I think the conclusion was that the authentication was hop-by-hop. > 9 I'm concerned that I don't see a way for a server to detect > a total ordering of accounting records for a session. This > would be useful, for example, when processing interim records. > The situation I'm concerned about is as follows. Suppose a > client sends an interim record to a proxy or relay agent. The > upstream link from the agent is experiencing a transient > problem. Or perhaps the agent crashes and reboots, but has > stored the pending records in non-volatile storage. In the > meantime, the client sends another interim message via another > path, either because it suspects a failure or because it is > using multiple peers for load-sharing. This second record > can be received first. I suspect that the easiest solution is > to require that Accounting-Record-Number be monotonically > increasing within a session. This is recommended in 9.8.3 already. > 13 Is there some document that discusses the end-to-end (and I mean > that literally here) Diameter authorization model? I know that > it was discussed in the WG, but I don't see anything on that > here. What's I'm looking for -- somewhere -- is some discussion > on how, say, a NAS "knows" that it will be paid when an > authorization comes from five proxies away. Also discussed in Atlanta that is hop by hop. There probably is still a need for a better discussion of the model. > 14 Non-ascii hyphens (which shouldn't be there anyway) OK John From owner-aaa-wg@merit.edu Tue Dec 3 11:20:09 2002 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 LAA00334 for ; Tue, 3 Dec 2002 11:20:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3AA991209; Tue, 3 Dec 2002 11:22:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF6FF912A3; Tue, 3 Dec 2002 11:22:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B959291209 for ; Tue, 3 Dec 2002 11:22:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 980485DF8B; Tue, 3 Dec 2002 11:22:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 5CDBE5DED5 for ; Tue, 3 Dec 2002 11:22:42 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 98F186A901; Tue, 3 Dec 2002 18:22:34 +0200 (EET) Message-ID: <3DECDA6C.1060802@kolumbus.fi> Date: Tue, 03 Dec 2002 18:23:08 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu, smb@research.att.com Subject: Re: [AAA-WG]: Steve's Comments (RE: Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>4.6 Why is the flag "MAY Encr" when confidentiality is mandatory? This name has caused enough confusion, let's change it. Let's just call it "Encryption" and then let the explanation in 4.6 explain what it means. >> What is the SHLD NOT column? It's never used in that table. I guess its there just for consistence, for the possibility that some AVP, some day, would have a rule about flags that involved SHLD NOT. We do NOT have any in the base, but for consistence perhaps all the Diameter specs should have the table in the same format. Anyways, I'm fine with removing this or keeping it. >> I don't see the reasoning for some of the settings of that >> flag. For example, I would think that the authentication- and >> authorization-related flags would require protection, to guard Just to make sure I understand the question right: s/flags/AVPs/? >> against deletion to prevent the operation from taking place, >> or to spoof the result. This also illustrates confusion between >> the need for integrity protection vs. confidentiality. It >> would be good to give some general guidance, for the benefit >> of people defining Diameter applications. > > > Any suggestions from the list on this one? Its a good question. I guess the main concern with "MAY Encr" column settings has been to protect user-related information such as user names. Some of the other information, such as type of auth/authz event may be necessary for intermediate agents. This kind of background should be stated in the base spec (but it isn't at the moment I think). Is there a specific AVP that appears to have a wrong setting? Jari From owner-aaa-wg@merit.edu Tue Dec 3 11:31:15 2002 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 LAA01110 for ; Tue, 3 Dec 2002 11:31:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77571912A3; Tue, 3 Dec 2002 11:33:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7271912A5; Tue, 3 Dec 2002 11:33:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF4DA912A3 for ; Tue, 3 Dec 2002 11:33:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id B761C5DDEB; Tue, 3 Dec 2002 11:33:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 070BE5DD9F for ; Tue, 3 Dec 2002 11:33:40 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3GX1G26950 for ; Tue, 3 Dec 2002 18:33:01 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 18:33:38 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 18:33:38 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 18:33:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Steve's Comments (RE: Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard) Date: Tue, 3 Dec 2002 18:33:37 +0200 Message-ID: Thread-Topic: [AAA-WG]: Steve's Comments (RE: Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard) Thread-Index: AcKa6DGlF+buamTfRxKym3tdkpEylgAAVm8w From: To: Cc: , X-OriginalArrivalTime: 03 Dec 2002 16:33:38.0316 (UTC) FILETIME=[BB7994C0:01C29AE9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01110 Hi Jari, > This name has caused enough confusion, let's change it. Let's just > call it "Encryption" and then let the explanation in 4.6 explain > what it means. Does the existing explanation still stand, or do you can you provide one? > >> What is the SHLD NOT column? It's never used in that table. > > I guess its there just for consistence, for the possibility that > some AVP, some day, would have a rule about flags that involved > SHLD NOT. We do NOT have any in the base, but for consistence > perhaps all the Diameter specs should have the table in the same > format. > > Anyways, I'm fine with removing this or keeping it. Lets keep it, it does no harn. > >> I don't see the reasoning for some of the settings of that > >> flag. For example, I would think that the authentication- and > >> authorization-related flags would require protection, to guard > > Just to make sure I understand the question right: s/flags/AVPs/? > > >> against deletion to prevent the operation from taking place, > >> or to spoof the result. This also illustrates confusion between > >> the need for integrity protection vs. confidentiality. It > >> would be good to give some general guidance, for the benefit > >> of people defining Diameter applications. > > > > > > Any suggestions from the list on this one? > > Its a good question. I guess the main concern with "MAY Encr" column > settings has been to protect user-related information such as user > names. Some of the other information, such as type of auth/authz event > may be necessary for intermediate agents. This kind of > background should > be stated in the base spec (but it isn't at the moment I think). Is > there a specific AVP that appears to have a wrong setting? I don't think so, if someone has an opinion, speak up, because I am soon planning on submitting the draft. John From owner-aaa-wg@merit.edu Tue Dec 3 11:36:47 2002 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 LAA01492 for ; Tue, 3 Dec 2002 11:36:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79CC3912A5; Tue, 3 Dec 2002 11:39:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4749A912A6; Tue, 3 Dec 2002 11:39:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DAD6912A5 for ; Tue, 3 Dec 2002 11:39:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C2AA5DEB7; Tue, 3 Dec 2002 11:39:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 01EC05DE32 for ; Tue, 3 Dec 2002 11:39:19 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 57FB26A901; Tue, 3 Dec 2002 18:39:18 +0200 (EET) Message-ID: <3DECDE58.6050705@kolumbus.fi> Date: Tue, 03 Dec 2002 18:39:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu, smb@research.att.com Subject: Re: [AAA-WG]: Steve's Comments (RE: Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Jari, > > >>This name has caused enough confusion, let's change it. Let's just >>call it "Encryption" and then let the explanation in 4.6 explain >>what it means. > > > Does the existing explanation still stand, or do you can you provide one? I think the explanation is fine, but the name of the column is very misleading. So just change the name. Jari From owner-aaa-wg@merit.edu Wed Dec 4 06:49:58 2002 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 GAA06662 for ; Wed, 4 Dec 2002 06:49:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 901259123A; Wed, 4 Dec 2002 06:52:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59E769123D; Wed, 4 Dec 2002 06:52:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E1999123A for ; Wed, 4 Dec 2002 06:52:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5131F5DE01; Wed, 4 Dec 2002 06:52:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E36895DD9C for ; Wed, 4 Dec 2002 06:52:33 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB4AkU020529 for ; Wed, 4 Dec 2002 02:46:30 -0800 Date: Wed, 4 Dec 2002 02:46:30 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: IETF 55 minutes available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The draft minutes for the AAA WG meeting at IETF 55 are now available for inspection: http://www.drizzle.com/~aboba/AAA/aaa-min55.txt From owner-aaa-wg@merit.edu Wed Dec 4 08:15:52 2002 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 IAA09246 for ; Wed, 4 Dec 2002 08:15:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 39E15912B7; Wed, 4 Dec 2002 08:18:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0975F912B8; Wed, 4 Dec 2002 08:18:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED92B912B7 for ; Wed, 4 Dec 2002 08:18:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB5945DEA6; Wed, 4 Dec 2002 08:18:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id F25E85DD9C for ; Wed, 4 Dec 2002 08:18:26 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB4DHlG29782 for ; Wed, 4 Dec 2002 15:17:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Dec 2002 15:18:25 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 15:18:25 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 15:18:25 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 15:18:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Call for review on SIP-AAA requirements Date: Wed, 4 Dec 2002 15:18:23 +0200 Message-ID: Thread-Topic: Call for review on SIP-AAA requirements Thread-Index: AcKbjetvNJUhVP7kSGi2glpy7JQTTwACX8Zg From: To: Cc: X-OriginalArrivalTime: 04 Dec 2002 13:18:24.0808 (UTC) FILETIME=[A017DA80:01C29B97] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA09246 Hi all, We are performing a call for review on the draft below. We would like to encourage people to read the draft and send comments to the authors and/or to the mailing list. http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-01.txt Note that we will be performing another call for review in the SIPPING WG in parallel to the AAA WG. We intend to add a couple of extra-requirements to the accounting part of the draft, but we will not release a new version until we have got comments from SIPPING, AAA, and the authors of the Diameter-based solution document. Thanks for your cooperation. Gonzalo & John From owner-aaa-wg@merit.edu Fri Dec 6 12:07:01 2002 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 MAA14080 for ; Fri, 6 Dec 2002 12:07:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08C6B9120F; Fri, 6 Dec 2002 12:09:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0CF6912DC; Fri, 6 Dec 2002 12:09:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD4659120F for ; Fri, 6 Dec 2002 12:09:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEB755DF61; Fri, 6 Dec 2002 12:09:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4CB595DE07 for ; Fri, 6 Dec 2002 12:09:39 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB6G3Ns02975 for ; Fri, 6 Dec 2002 08:03:23 -0800 Date: Fri, 6 Dec 2002 08:03:23 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Reminder: AAA WG last call on NASREQ-10 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call is now ongoing on NASREQ-10 and will end December 28, 2002. So far we have had no comments -- and yet it seems unlikely that the document is perfect as it is, and ready for sending off to the IESG. At IETF 55, only four people admitted to having read the document -- and two of those people were the chairs. So if you haven't read the document yet, please put some time aside to do so. It's available at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt No comment is too small. As usual, please mail your comments to aaa-wg@merit.edu in the format used for AAA issues, described at: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Sat Dec 7 20:23:55 2002 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 UAA11453 for ; Sat, 7 Dec 2002 20:23:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7524791201; Sat, 7 Dec 2002 20:26:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B28091208; Sat, 7 Dec 2002 20:26:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5782B91201 for ; Sat, 7 Dec 2002 20:26:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29E355DE41; Sat, 7 Dec 2002 20:26:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A82705DD93 for ; Sat, 7 Dec 2002 20:26:33 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB80KAp11987 for ; Sat, 7 Dec 2002 16:20:10 -0800 Date: Sat, 7 Dec 2002 16:20:10 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Transport-09 strawman Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk A strawman version of Transport-09 addressing IESG comments is avaialble at: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-09.txt The comments addressed include a requested reference to RFC 1750. There has also been a request for guidance on the number of SCTP streams to be supported. Any comments on how many streams might be appropriate? The draft describes this as depending on the implementation. One thought is that on a Diameter client, the number of streams might be proportional to the number of ports on the NAS. If there is one stream per NAS port going from the NAS to a proxy, then there is no possibility of head-of-line blocking. On a proxy, the number of streams going from the proxy to the AAA server is harder to estimate. It probably should be determined by the peak number of simultaneous AAA sessions between the proxy and each AAA server. From owner-aaa-wg@merit.edu Sun Dec 8 04:21:46 2002 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 EAA27986 for ; Sun, 8 Dec 2002 04:21:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A379F91208; Sun, 8 Dec 2002 04:24:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B23F91210; Sun, 8 Dec 2002 04:24:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 428D791208 for ; Sun, 8 Dec 2002 04:24:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A1F45DDB3; Sun, 8 Dec 2002 04:24:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 319205DD9A for ; Sun, 8 Dec 2002 04:24:23 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB89PbW08298 for ; Sun, 8 Dec 2002 11:25:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 8 Dec 2002 11:24:22 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 8 Dec 2002 11:24:21 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 8 Dec 2002 11:24:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Transport-09 strawman Date: Sun, 8 Dec 2002 11:24:20 +0200 Message-ID: Thread-Topic: [AAA-WG]: Transport-09 strawman Thread-Index: AcKeWOiDrUSy8ov7RQC1YDlKM+BoKQAQlWuQ From: To: , X-OriginalArrivalTime: 08 Dec 2002 09:24:21.0790 (UTC) FILETIME=[97745BE0:01C29E9B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA27986 Hi Bernard, > Any comments on how many streams might be appropriate? The draft describes > this as depending on the implementation. > > One thought is that on a Diameter client, the number of streams might be > proportional to the number of ports on the NAS. If there is one stream per > NAS port going from the NAS to a proxy, then there is no possibility of > head-of-line blocking. > > On a proxy, the number of streams going from the proxy to the AAA server > is harder to estimate. It probably should be determined by the peak number > of simultaneous AAA sessions between the proxy and each AAA server. Those should be a lower limit. However, one possibility is to simply recommend using maximum number of streams possible (64k). On TSVWG some time ago, there was a discussion about stream usage and it was noted that on several implementations, inactive streams don't consume any kernel resources, so limiting the total number doesn't save anything. John From owner-aaa-wg@merit.edu Sun Dec 8 09:55:51 2002 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 JAA02617 for ; Sun, 8 Dec 2002 09:55:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5F6491214; Sun, 8 Dec 2002 09:58:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97D3491218; Sun, 8 Dec 2002 09:58:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7143091214 for ; Sun, 8 Dec 2002 09:58:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 527155DFFA; Sun, 8 Dec 2002 09:58:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 308A85DFF1 for ; Sun, 8 Dec 2002 09:58:28 -0500 (EST) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18L2t1-000Otz-00; Sun, 08 Dec 2002 06:58:27 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport-09 strawman References: Message-Id: Date: Sun, 08 Dec 2002 06:58:27 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > A strawman version of Transport-09 addressing IESG comments is avaialble > at: > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-09.txt > > The comments addressed include a requested reference to RFC 1750. There > has also been a request for guidance on the number of SCTP streams to be > supported. uh, this document was approved by the iesg at the conf call of 2002.10.31, though updating its datatracker entry seems to have fallen through the cnri cracks . how much do you need to change it? randy From owner-aaa-wg@merit.edu Sun Dec 8 10:55:55 2002 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 KAA03817 for ; Sun, 8 Dec 2002 10:55:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EBC1B91211; Sun, 8 Dec 2002 10:58:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B98FB91218; Sun, 8 Dec 2002 10:58:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B16FF91211 for ; Sun, 8 Dec 2002 10:58:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 980985E000; Sun, 8 Dec 2002 10:58:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 30D5A5DFDB for ; Sun, 8 Dec 2002 10:58:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB8Eq5H30860; Sun, 8 Dec 2002 06:52:05 -0800 Date: Sun, 8 Dec 2002 06:52:05 -0800 (PST) From: Bernard Aboba To: Randy Bush Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport-09 strawman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > uh, this document was approved by the iesg at the conf call of > 2002.10.31, though updating its datatracker entry seems to have > fallen through the cnri cracks . how much do you need to > change it? Only to respond to IESG comments. From owner-aaa-wg@merit.edu Sun Dec 8 10:58:42 2002 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 KAA03868 for ; Sun, 8 Dec 2002 10:58:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB97191218; Sun, 8 Dec 2002 11:00:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8356391224; Sun, 8 Dec 2002 11:00:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 672D991218 for ; Sun, 8 Dec 2002 11:00:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 468D45DFCC; Sun, 8 Dec 2002 11:00:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C05005DFCB for ; Sun, 8 Dec 2002 11:00:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB8EsMT30984; Sun, 8 Dec 2002 06:54:22 -0800 Date: Sun, 8 Dec 2002 06:54:22 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Transport-09 strawman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Those should be a lower limit. However, one possibility is to simply > recommend using maximum number of streams possible (64k). On TSVWG > some time ago, there was a discussion about stream usage and it was > noted that on several implementations, inactive streams don't consume > any kernel resources, so limiting the total number doesn't save > anything. But on other implementations inactive streams do consume kernel resources, so using the maximum number may have penalties. Here is some suggested text: "n a Diameter client, the number of streams may be determined by the maximum number of peak users on the NAS. If a stream is available per user, then this should be sufficient to prevent head-of-line blocking. On a Diameter proxy, the number of streams may be determined by the maximum number of peak sessions in progress from that proxy to each downstream AAA server." From owner-aaa-wg@merit.edu Sun Dec 8 11:07:35 2002 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 LAA04005 for ; Sun, 8 Dec 2002 11:07:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 78DA091224; Sun, 8 Dec 2002 11:10:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48A7C91231; Sun, 8 Dec 2002 11:10:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E0C691224 for ; Sun, 8 Dec 2002 11:10:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 05A745DF6D; Sun, 8 Dec 2002 11:10:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id D906E5DDBB for ; Sun, 8 Dec 2002 11:10:12 -0500 (EST) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18L40S-000P4X-00; Sun, 08 Dec 2002 08:10:12 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport-09 strawman References: Message-Id: Date: Sun, 08 Dec 2002 08:10:12 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> uh, this document was approved by the iesg at the conf call of >> 2002.10.31, though updating its datatracker entry seems to have >> fallen through the cnri cracks . how much do you need to >> change it? > Only to respond to IESG comments. cool. but please be delicate. randy From owner-aaa-wg@merit.edu Sun Dec 8 12:15:45 2002 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 MAA05242 for ; Sun, 8 Dec 2002 12:15:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF4E691209; Sun, 8 Dec 2002 12:18:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD1C591231; Sun, 8 Dec 2002 12:18:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF22F91209 for ; Sun, 8 Dec 2002 12:18:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id A5C535DF99; Sun, 8 Dec 2002 12:18:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 38BEA5DE59 for ; Sun, 8 Dec 2002 12:18:23 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gB8GBq102765; Sun, 8 Dec 2002 08:11:52 -0800 Date: Sun, 8 Dec 2002 08:11:52 -0800 (PST) From: Bernard Aboba To: Randy Bush Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Transport-09 strawman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > cool. but please be delicate. I'll try to be. There are only 2-3 changes to make (which can be seen by doing a diff). From owner-aaa-wg@merit.edu Tue Dec 10 23:54:50 2002 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 XAA01586 for ; Tue, 10 Dec 2002 23:54:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03117912D9; Tue, 10 Dec 2002 23:57:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C84FA912DA; Tue, 10 Dec 2002 23:57:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DF0E912D9 for ; Tue, 10 Dec 2002 23:57:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 76AC45DE70; Tue, 10 Dec 2002 23:57:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id BF24E5DDB5 for ; Tue, 10 Dec 2002 23:57:28 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBB4wlW20573 for ; Wed, 11 Dec 2002 06:58:47 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Dec 2002 06:57:26 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 06:57:26 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 06:57:25 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 06:57:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: charset issue with draft-ietf-aaa-diameter-15.txt Date: Wed, 11 Dec 2002 06:57:24 +0200 Message-ID: Thread-Topic: [AAA-WG]: charset issue with draft-ietf-aaa-diameter-15.txt Thread-Index: AcKgiuunPZehjNg1TsaU7aW7GwrxDAARpawg From: To: Cc: X-OriginalArrivalTime: 11 Dec 2002 04:57:24.0804 (UTC) FILETIME=[CBD38040:01C2A0D1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA01586 Hi all, Trying to close off all IESG comments, and am trying to address the charset issue. Below is a mail from Patrik. I propose to create a seperate draft for a Diameter stringprep. Does anyone have any problems with this approach or have an alternative solution? Thanks, John > -----Original Message----- > From: ext Patrik Fältström [mailto:paf@cisco.com] > Sent: 10 December, 2002 22:30 > To: Loughney John (NRC/Helsinki) > Cc: randy@psg.com > Subject: Re: [AAA-WG]: charset issue with > draft-ietf-aaa-diameter-15.txt > > > On tisdag, dec 10, 2002, at 20:57 Europe/Stockholm, > wrote: > > > Do you have any existing references that I could base doing > this work? > > Absolutely, for example the iSCSI specification > (draft-ietf-ips-iscsi-string-prep-03.txt) for comparison of > iSCSI unit > names (I think), and kerberos (draft-ietf-krb-wg-utf8-profile-00.txt, > which unfortunately has expired) for comparison of kerberos Realms. > > > At IETF 55, the WG pushed back on this solution (it was > presented to > > them). > > We are in a bit of a bind, as this is extremely late, about > 1 and half > > years, and the WG is fearful of further delays, without supporting > > reasons (i.e. - the wg doesn't see why this is needed). > > I understand this. > > The problem with _not_ doing a stringprep profile (a very > simple thing) > is that many characters is allowed to be represented in more than one > way. Especially if you have a character with more than one diacritic. > The stringprep profile ensure that the diacritics are sorted > in one and > only one way, so two implementations of Unicode/UTF-8 which might use > different internal representation will store "equal" strings in your > protocol. > > Another example which might make sense, are the two following strings > equal or not: > > fooXbar > > where X is either of the following: > > + U+0020 SPACE > + U+00A0 NO-BREAK SPACE > - U+1361 ETHIOPIC WORDSPACE > - U+1680 OGHAM SPACE MARK > + U+2002 EN SPACE > + U+2003 EM SPACE > + U+2004 THREE-PER-EM SPACE > + U+2005 FOUR-PER-EM SPACE > + U+2006 SIX-PER-EM SPACE > + U+2007 FIGURE SPACE > + U+2008 PUNCTUATION SPACE > + U+2009 THIN SPACE > + U+200A HAIR SPACE > - U+200B ZERO WIDTH SPACE > - U+200C ZERO WIDTH NON-JOINER > - U+200D ZERO WIDTH JOINER > + U+202F NARROW NO-BREAK SPACE > - U+2420 SYMBOL FOR SPACE > + U+3000 IDEOGRAPHIC SPACE > - U+303F IDEOGRAPHIC HALF FILL SPACE > - U+FEFF ZERO WIDTH NO-BREAK SPACE > - U+E0020 TAG SPACE > > Answer: With a stringprep profile, it is defined that the > ones with '+' > before them are "equal". Not the ones with '-'. You do today > say all of > these characters are different, which is fine too, but you have to be > explicit about it -- and that is what stringprep give you an > ability to > be. I would not recommend it though. > > Similar examples can be found with ordinary characters and not space. > > One example are the following two sequences: > > U+00A8 (DIAERESIS) > > U+0020 (SPACE) + U+0308 (COMBINING DIAERESIS) > > Both are technically correct according to the Unicode > specification and > they produce _exactly_ the same result when used in any > Unicode engine. > > paf > > From owner-aaa-wg@merit.edu Wed Dec 11 00:31:46 2002 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 AAA02452 for ; Wed, 11 Dec 2002 00:31:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF3839120D; Wed, 11 Dec 2002 00:34:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AFE7912DA; Wed, 11 Dec 2002 00:34:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A52249120D for ; Wed, 11 Dec 2002 00:34:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F4855DF3B; Wed, 11 Dec 2002 00:34:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1B7245DEAB for ; Wed, 11 Dec 2002 00:34:26 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBB4Rhx07330; Tue, 10 Dec 2002 20:27:43 -0800 Date: Tue, 10 Dec 2002 20:27:43 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: charset issue with draft-ietf-aaa-diameter-15.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Trying to close off all IESG comments, and am trying to address > the charset issue. Below is a mail from Patrik. I propose > to create a seperate draft for a Diameter stringprep. > > Does anyone have any problems with this approach or have an > alternative solution? I'm just curious as to what we are trying to compare, and why this needs a unique draft. As I understand it, we are talking primarily about FQDNs, no? If so, this should be a generic draft, not something unique to AAA. Or are there other things? We've already discussed why things like filter lists or routes should be in pure ASCII, and so don't need stringprep. From owner-aaa-wg@merit.edu Wed Dec 11 13:04:47 2002 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 NAA14920 for ; Wed, 11 Dec 2002 13:04:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 714E19120F; Wed, 11 Dec 2002 13:07:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4533391242; Wed, 11 Dec 2002 13:07:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F24909120F for ; Wed, 11 Dec 2002 13:07:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id D90745DF7F; Wed, 11 Dec 2002 13:07:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 2D9715DF71 for ; Wed, 11 Dec 2002 13:07:26 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBBI8jW20030 for ; Wed, 11 Dec 2002 20:08:45 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 11 Dec 2002 20:07:24 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 20:07:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Ambiguity in the description of Session-Id Date: Wed, 11 Dec 2002 20:07:23 +0200 Message-ID: <9E3407CE45911B4097632389B77B202301870260@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: IETF 55 minutes available Thread-Index: AcKbjIT3H9JpFLyPSv2DUb52OhyjswFsJd5A From: To: X-OriginalArrivalTime: 11 Dec 2002 18:07:23.0753 (UTC) FILETIME=[27CD2590:01C2A140] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA14920 Hi, I see that there is some ambiguity in the description of Sesion-Id AVP in section 8.8 of base-15. "The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see section 4.4). The remainder of the Session-Id MAY be any sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element): ;;[;]" The description indicates that a Session-Id with format "[unique optional value>]". If yes what is the delimiter to separate the DiameterIdentity from the unique optional value. Kishore From owner-aaa-wg@merit.edu Wed Dec 11 23:03:43 2002 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 XAA02507 for ; Wed, 11 Dec 2002 23:03:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68AEF91221; Wed, 11 Dec 2002 23:06:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3477B91225; Wed, 11 Dec 2002 23:06:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D55F291221 for ; Wed, 11 Dec 2002 23:06:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id BCD665DDED; Wed, 11 Dec 2002 23:06:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web80107.mail.yahoo.com (web80107.mail.yahoo.com [66.163.169.80]) by segue.merit.edu (Postfix) with SMTP id 1FE7F5DDE7 for ; Wed, 11 Dec 2002 23:06:23 -0500 (EST) Message-ID: <20021212035454.16620.qmail@web80107.mail.yahoo.com> Received: from [66.140.44.52] by web80107.mail.yahoo.com via HTTP; Wed, 11 Dec 2002 19:54:54 PST Date: Wed, 11 Dec 2002 19:54:54 -0800 (PST) From: Behcet Sarikaya Reply-To: sarikaya@ieee.org Subject: [AAA-WG]: Re: draft-ietf-aaa-diameter-mobileip-13.txt To: aaa-wg@merit.edu In-Reply-To: <20021211151635.42795.qmail@web80103.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Dear all, The draft says: the HA generates a unique Acct-Multi-Session-Id when receiving an HAR for a new session, and returns this same value in every HAA for the session. This Acct- Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Acct-Multi-Session-Id in the accounting messages. My question is if HA is dynamically allocated and is constantly changing, how can we assure Acct-Multi-Session-Id is going to stay the same? Regards, --behcet From owner-aaa-wg@merit.edu Thu Dec 12 18:02:14 2002 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 SAA16691 for ; Thu, 12 Dec 2002 18:02:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 218BD91252; Thu, 12 Dec 2002 18:04:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E567B912E4; Thu, 12 Dec 2002 18:04:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DC9F91252 for ; Thu, 12 Dec 2002 18:04:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAB4D5DE1A; Thu, 12 Dec 2002 18:04:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6A8165DDFA for ; Thu, 12 Dec 2002 18:04:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBCLw7o15544 for ; Thu, 12 Dec 2002 13:58:07 -0800 Date: Thu, 12 Dec 2002 13:58:07 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: AAA WG Last Call on NASREQ-10 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a reminder that AAA WG Last Call is ongoing on draft-ietf-aaa-diameter-nasreq-10.txt, which is being considered for advancement as an IETF Proposed Standard. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt So far, we have not had a single comment on this draft -- which only 4 people indicated they had read at IETF 55. Note that the ability of AAA WG to take on new work items is in part constrained by our ability to finish old ones. So even if NASREQ is not your main interest, please put some time aside to read it and send in your comments during the upcoming Holidays. AAA WG last call on NASREQ-10 will run until December 28, 2002. Please send comments to the authors or aaa-wg@merit.edu, using the Issues submission template found at: http://www.drizzle.com/~aboba/AAA/issues.html In particular, it is requested that commenters not only identify problems in the draft, but send text to fix the identified issues. From owner-aaa-wg@merit.edu Fri Dec 13 06:38:03 2002 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 GAA20849 for ; Fri, 13 Dec 2002 06:38:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4203391210; Fri, 13 Dec 2002 06:40:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DC889121D; Fri, 13 Dec 2002 06:40:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB95F91210 for ; Fri, 13 Dec 2002 06:40:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id CEF865E0DE; Fri, 13 Dec 2002 06:40:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 953715DF36 for ; Fri, 13 Dec 2002 06:40:47 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D14086A901; Fri, 13 Dec 2002 13:40:40 +0200 (EET) Message-ID: <3DF9C759.9080702@kolumbus.fi> Date: Fri, 13 Dec 2002 13:41:13 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: REMINDER: AAA WG Last Call on NASREQ-10 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here's a few comments: - Title and abstract contain abbreviations. Consider changing this to avoid complaints from the RFC editor. How valid is "NASREQ" for the name of a protocol anyway? How about "Diameter Application for Network Access Servers"? (But this could affect base too, but perhaps it can be done in authors 48 hours.) Expand AAA in abstract. - " ... satisfies NAS-related requirements defined in RFC 2989 [AAACRIT]." => " ... satisfies typical requirements for in the network access domain" and then you can refer to the requirements in the intro. - "Given that it is expected that initial deployments of the Diameter protocol will include legacy systems. This application was ..." => "Initial deployments of the Diameter protocol are expected include legacy systems. Therefore, this application was..." - Contents indentation could be prettier, e.g not change when the section numbers go from 9 to 10. - Consider including only top 2..3 levels in the contents list and making a separate List of AVP Definitions page to follow the contents page, with each AVP definition section listed in alphabetical order. - Shorten the title of 6.4 to "AVPs that can be Translated" and 6.3 to "Prohibited Attributes". - In abstract, "re-using the RADIUS attribute space"... I wonder if we reuse the SPACE or the ATTRIBUTES. It seems to me that its the latter, we have a new Diameter space for new attributes. THe reader might be confused to think the radius avp space limitations apply here too. - Reference [EAP] appears no longer necessary. - Why are RADIUS references informative? We speak of RADIUS attrs in the document and the reference is still not normative?! - Reference identities might be better aligned, e.g. RADTunnels, and RADTUNNLACCT. - Is the 8.3 reference to IANAConsid correct? IANA holds the namespace but isn't it the Diameter base that defines the namespace? - Add to section 9 the following: "The security considerations of the Diameter protocol itself have been discussed in [DiamBASE].". - Section 8 should contain some statement about the IANA allocation policies of RADIUS attr enumerated values. Reference some document(s)? - In section 5 at the text "Authentication or Authorization transaction or the end of a Session.": Isn't the last "or" really an and? I mean you want ACRs on both, right? - Also, ar the ACRs sent on both auth and authz events if they are done separately? Perhaps you should break this text into a set of individual normative requirements. Please make sure you say how many messages are sent if authz and auth both happen in the same AA request. - In 4.3.11 there's a missing space (?) in "proprietarySingleLink/MultiLink" - There's a concatenation procedure mentioned in 6.4. Could we say explicitly for which attributes it can be done? - Missing newline after the title of section 7. - Having the 7.1 table start on a new page is useless because it will not fit a single page anyway. - In 8.2. "This specification assigns the values 363-366 and 400-414 from the". I'm not sure I understand the 400-414 because only 400, 403, and 409-412 can be found from the nasreq document. Jari From owner-aaa-wg@merit.edu Fri Dec 13 13:40:22 2002 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 NAA01370 for ; Fri, 13 Dec 2002 13:40:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F14E8912F1; Fri, 13 Dec 2002 13:43:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6994912F2; Fri, 13 Dec 2002 13:43:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5320912F1 for ; Fri, 13 Dec 2002 13:43:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FE805DFCC; Fri, 13 Dec 2002 13:43:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web40908.mail.yahoo.com (web40908.mail.yahoo.com [66.218.78.205]) by segue.merit.edu (Postfix) with SMTP id 1D9175DDB2 for ; Fri, 13 Dec 2002 13:43:06 -0500 (EST) Message-ID: <20021213184305.10622.qmail@web40908.mail.yahoo.com> Received: from [207.3.232.170] by web40908.mail.yahoo.com via HTTP; Fri, 13 Dec 2002 10:43:05 PST Date: Fri, 13 Dec 2002 10:43:05 -0800 (PST) From: Dilip Subject: [AAA-WG]: Suggestion to modify State Machine in base document To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Dilip Patel Submitter email address: dilris@yahoo.com Document: Base Comment type:T Priority: 2 Section: 5.6 Explanation of issue: In the peer state machine. for the peer state Wait-Conn-Ack/Elect The event for which the peer is waiting is an ACK or NACK from the transport layer for the Intiator connection (I). In this senario a Timeout Event occuring would imply that the ACK/NACK event didint occur in the set time period. The current State machine requires that in this case action to be taken is Error and next state moved is Closed. The Issue is that the Responder (R) Connection has already been established with the peer which is waiting to receive a CEA on R connection. With the current state machine There will be no CEA send and that would result in a Timeout on the peers end (peers state on the other host). And thus closing of this R connection also. SUGESTION: ---------- If instead of taking a Error action and making the next state as CLOSED. The state machine could treat the Timeout as same as a I-Rcv-Conn-Nack and thus taking action R-Snd-CEA changing the next state to R-Open. This would establish an connection between the 2 peers immediately instead of waiting another few seconds before the 2 peers try establishing a connection again. Requested change: ---------------- State machine change from: state event action next state -------------------------------------------------------- Wait-Conn-Ack/ Timeout Error Closed Elect State Machine change TO: state event action next state -------------------------------------------------------- Wait-Conn-Ack/ Timeout R-Snd-CEA R-Open Elect Regards Dilip Patel __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-aaa-wg@merit.edu Fri Dec 13 13:58:42 2002 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 NAA01815 for ; Fri, 13 Dec 2002 13:58:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 745D1912F2; Fri, 13 Dec 2002 14:00:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3998E912F3; Fri, 13 Dec 2002 14:00:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31E88912F2 for ; Fri, 13 Dec 2002 14:00:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CD165DF7C; Fri, 13 Dec 2002 14:00:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 427605DEB9 for ; Fri, 13 Dec 2002 14:00:43 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBDHrmv16981; Fri, 13 Dec 2002 09:53:48 -0800 Date: Fri, 13 Dec 2002 09:53:48 -0800 (PST) From: Bernard Aboba To: Dilip Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Suggestion to modify State Machine in base document In-Reply-To: <20021213184305.10622.qmail@web40908.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Filed as issue 391. On Fri, 13 Dec 2002, Dilip wrote: > Submitter name: Dilip Patel > Submitter email address: dilris@yahoo.com > Document: Base > Comment type:T > Priority: 2 > Section: 5.6 > Explanation of issue: > > In the peer state machine. > for the peer state Wait-Conn-Ack/Elect > The event for which the peer is waiting is an ACK or > NACK from the transport layer for the Intiator > connection (I). > In this senario a Timeout Event occuring would imply > that the ACK/NACK event didint occur in the set time > period. > The current State machine requires that in this case > action to be taken is Error and next state moved is > Closed. > > The Issue is that the Responder (R) Connection has > already been established with the peer which is > waiting to receive a CEA on R connection. > With the current state machine There will be no CEA > send and that would result in a Timeout on the peers > end (peers state on the other host). And thus closing > of this R connection also. > > SUGESTION: > ---------- > If instead of taking a Error action and making the > next state as CLOSED. > The state machine could treat the Timeout as same as a > > I-Rcv-Conn-Nack and thus taking action R-Snd-CEA > changing the next state to R-Open. > > This would establish an connection between the 2 peers > immediately instead of waiting another few seconds > before the 2 peers try establishing a connection > again. > > Requested change: > ---------------- > State machine change from: > state event action next state > -------------------------------------------------------- > Wait-Conn-Ack/ Timeout Error Closed > Elect > > State Machine change TO: > state event action next state > -------------------------------------------------------- > Wait-Conn-Ack/ Timeout R-Snd-CEA R-Open > Elect > > > > Regards > Dilip Patel > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > From owner-aaa-wg@merit.edu Fri Dec 13 14:19:39 2002 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 OAA02608 for ; Fri, 13 Dec 2002 14:19:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A819912F5; Fri, 13 Dec 2002 14:22:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BDBB912F6; Fri, 13 Dec 2002 14:22:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5DCA912F5 for ; Fri, 13 Dec 2002 14:22:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6F0A5DF04; Fri, 13 Dec 2002 14:22:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 0B2195DDE0 for ; Fri, 13 Dec 2002 14:22:20 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBDJLa017943 for ; Fri, 13 Dec 2002 21:21:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Dec 2002 21:22:18 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 21:22:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Ambiguity in the description of Session-Id Date: Fri, 13 Dec 2002 21:22:12 +0200 Message-ID: <9E3407CE45911B4097632389B77B2023017DFAA8@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKi2hoIdCx+EvCPRLWDbfL2LG5ZIAAArcww From: To: X-OriginalArrivalTime: 13 Dec 2002 19:22:12.0605 (UTC) FILETIME=[F0311AD0:01C2A2DC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA02608 Descriptiom of the issue: Ambiguity in Session-Id description Submitter name: Ghadiyaram Venkata Kishore Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, Date first submitted: 13 December, 2002 Reference: Document: Base Comment type: T Priority: S Section: Rationale/Explanation of issue: Section 8.8 describing the Session-Id AVP is ambiguous about the mandatory part and the optional part of the Session-Id. From the description it is possible to have a Session-Id of the form [unique optional value>] where there is no delimiter between the DiameterIdentity and the remaining portion of the Session-Id. So it is not possible to validate the correctness of the Session-Id. It may not also be possible to specify a delimiter as the DiameterIdentity is of type UTF8String. Is there a necessity for the mandatory part of the Session-Id. Why should it be mandatory that the Session-Id should start with DiameterIdentity. The whole Session-Id could be implementation dependant and the implementation should ensure the uniqueness. Requested Change : In section 8.8 remove the lines " The Session-Id includes a mandatory portion and an implementation-defined portion;" and " The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see section 4.4)." -----Original Message----- From: ext Bernard Aboba [mailto:aboba@internaut.com] Sent: 13. December 2002 19:55 To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id Assuming that your question isn't answered, please file an issue in the format described in: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Sat Dec 14 22:55:59 2002 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 WAA17670 for ; Sat, 14 Dec 2002 22:55:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 34FDF9123B; Sat, 14 Dec 2002 22:58:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2D889125A; Sat, 14 Dec 2002 22:58:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06D709123B for ; Sat, 14 Dec 2002 22:58:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF4FA5E0FD; Sat, 14 Dec 2002 22:58:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BB50A5E09B for ; Sat, 14 Dec 2002 22:58:37 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBF2pSj28279; Sat, 14 Dec 2002 18:51:29 -0800 Date: Sat, 14 Dec 2002 18:51:28 -0800 (PST) From: Bernard Aboba To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id In-Reply-To: <9E3407CE45911B4097632389B77B2023017DFAA8@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Filed as Issue 392. On Fri, 13 Dec 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > Descriptiom of the issue: Ambiguity in Session-Id description > Submitter name: Ghadiyaram Venkata Kishore > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > Date first submitted: 13 December, 2002 > Reference: > Document: Base > Comment type: T > Priority: S > Section: > Rationale/Explanation of issue: > Section 8.8 describing the Session-Id AVP is ambiguous about the mandatory part and the optional part of the Session-Id. From the description it is possible to have a Session-Id of the form [unique optional value>] where there is no delimiter between the DiameterIdentity and the remaining portion of the Session-Id. So it is not possible to validate the correctness of the Session-Id. It may not also be possible to specify a delimiter as the DiameterIdentity is of type UTF8String. > > Is there a necessity for the mandatory part of the Session-Id. Why should it be mandatory that the Session-Id should start with DiameterIdentity. The whole Session-Id could be implementation dependant and the implementation should ensure the uniqueness. > > Requested Change : > > In section 8.8 remove the lines > > " The Session-Id includes a mandatory portion and an implementation-defined portion;" > > and > > " The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see section 4.4)." > > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 13. December 2002 19:55 > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > Assuming that your question isn't answered, please file an issue in the > format described in: > > http://www.drizzle.com/~aboba/AAA/issues.html > > From owner-aaa-wg@merit.edu Sun Dec 15 00:27:41 2002 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 AAA18747 for ; Sun, 15 Dec 2002 00:27:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 420689125A; Sun, 15 Dec 2002 00:30:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2F459125C; Sun, 15 Dec 2002 00:30:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D4AB9125A for ; Sun, 15 Dec 2002 00:30:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 699B25DE3D; Sun, 15 Dec 2002 00:30:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from shardagate.mahindrabt.com (shardagate.mahindrabt.com [203.124.158.2]) by segue.merit.edu (Postfix) with ESMTP id 6EDBD5DE00 for ; Sun, 15 Dec 2002 00:30:07 -0500 (EST) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA06807 for ; Sun, 15 Dec 2002 11:00:03 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Sun, 15 Dec 2002 10:50:07 +0530 Date: Sun, 15 Dec 2002 10:50:07 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: skawade@mahindrabt.com Received: from dscp01801 ([10.5.4.5]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id KAA28273 for ; Sun, 15 Dec 2002 10:59:52 +0530 X-MSReally-From: skawade@mahindrabt.com Message-ID: <003e01c2a3fa$55648e00$0504050a@mahindrabt.com> From: "Santosh Kawade" To: Subject: [AAA-WG]: Diameter Mobile-IP implementation Date: Sun, 15 Dec 2002 10:55:08 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C2A428.6EFB3840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C2A428.6EFB3840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sir, We are implementing a Diameter Stack and MIPv4 application but = have some doubts. Could you please give us a clarification about the = following cases: 1. A diameter mobile IPv4 implementation related : (a) How is communication link between Diameter Mobile IPv4 server and Foreign agent established. For e.g Does the FA send AMR messages to the default TBD port of diameter [AAAF] server. (b) Are the AMR messages send per service request. Meaning that the = first AMR deals with just getting authenticating and subsequent AMR's will deal with any specific = service request. 2. Diameter Session layer [ Sec 8.1 ] Authorization state machine. a. Has the point 1.b anything to do with Grant Access and Provide = Service Action items in Authorization state machine [ CLIENT STATEFUL ] b. What is the significance of setting timers at both the client [ = AAAF ] and server [ AAAH] ends when they are in open mode for a specific = session ? CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Open Session-Timeout Expires on Send STR Discon Access Device SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Open Session-Timeout expires on Cleanup Idle home server Thanks, Santosh ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_003B_01C2A428.6EFB3840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Sir,
        We are implementing a Diameter Stack = and MIPv4=20 application but have some doubts. Could you please give us a = clarification about=20 the following cases:

1. A diameter mobile IPv4 implementation  related = :
 =20 (a)  How is communication link between Diameter Mobile IPv4 = server=20 and
Foreign agent established.
    For e.g Does the = FA send=20 AMR  messages to the default TBD port of
diameter [AAAF]=20 server.

  (b) Are the AMR messages send per service request. = Meaning=20 that the first
AMR deals with just getting
   =20 authenticating and subsequent AMR's will deal with any specific=20 service
request.

2. Diameter Session layer [ Sec 8.1 ] = Authorization=20 state machine.

 a.   Has the point 1.b anything to = do with=20 Grant Access and Provide Service
Action items in Authorization = state=20 machine  [ CLIENT STATEFUL ]

b.   What is the = significance=20 of setting timers at both the client [ AAAF ]
and server [ AAAH] ends = when=20 they are in open mode for a  specific session=20 ?

          &nbs= p;            = ;      =20 CLIENT, STATEFUL
      = State    =20 Event           &n= bsp;           &nb= sp; =20 Action     New = State
     =20 -------------------------------------------------------------
 &n= bsp;   =20 Open      Session-Timeout Expires=20 on     Send STR  =20 Discon
          &nb= sp;        =20 Access=20 Device

          = ;            =       =20 SERVER, STATEFUL
      = State    =20 Event           &n= bsp;           &nb= sp; =20 Action     New = State
     =20 -------------------------------------------------------------
 &n= bsp;   =20 Open      Session-Timeout expires=20 on     Cleanup   =20 Idle
           = ;        =20 home server

Thanks,
Santosh
 

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_003B_01C2A428.6EFB3840-- From owner-aaa-wg@merit.edu Sun Dec 15 00:52:21 2002 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 AAA19010 for ; Sun, 15 Dec 2002 00:52:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46A639125C; Sun, 15 Dec 2002 00:55:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 145409125D; Sun, 15 Dec 2002 00:55:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFBD49125C for ; Sun, 15 Dec 2002 00:55:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE6FF5E015; Sun, 15 Dec 2002 00:55:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from shardagate.mahindrabt.com (shardagate.mahindrabt.com [203.124.158.2]) by segue.merit.edu (Postfix) with ESMTP id 2FF935E113 for ; Sun, 15 Dec 2002 00:55:03 -0500 (EST) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA08937 for ; Sun, 15 Dec 2002 11:24:59 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Sun, 15 Dec 2002 11:14:54 +0530 Date: Sun, 15 Dec 2002 11:14:54 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: skawade@mahindrabt.com Received: from dscp01801 ([10.5.4.5]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id LAA31781; Sun, 15 Dec 2002 11:24:41 +0530 X-MSReally-From: skawade@mahindrabt.com Message-ID: <006d01c2a3fd$cc802a00$0504050a@mahindrabt.com> From: "Santosh Kawade" To: Cc: "Bernard Aboba" References: Subject: Re: [AAA-WG]: Diameter Mobile-IP implementation Date: Sun, 15 Dec 2002 11:19:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Description of issue : Diameter mobile IPv4 implementation related Submitter name : Santosh Kawade Submitter email address : skawade@mahindrabt.com Date first submitted : 15-Dec-2002 Reference : NA Document: Document Requiring change [base, nasreq, mobileip, cms] : Base 8.1 Comment type: ['T'echnical | 'E'ditorial] : T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] : NA Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Sir your clarification is needed for our understanding for implementing Diameter Mobile IPv4 application. 1 (a) How is communication link between Diameter Mobile IPv4 server and Foreign agent established. For e.g Does the FA send AMR messages to the default TBD port of diameter [AAAF] server. (b) Are the AMR messages send per service request. Meaning that the first AMR deals with just getting authenticating and subsequent AMR's will deal with any specific service request. 2. Diameter Session layer [ Sec 8.1 ] Authorization state machine. a. Has the point 1.b anything to do with Grant Access and Provide Service Action items in Authorization state machine [ CLIENT STATEFUL ] b. What is the significance of setting timers at both the client [ AAAF ] and server [ AAAH] ends when they are in open mode for a specific session ? CLIENT, STATEFUL State Event Action New State ------------------------------------------------------------- Open Session-Timeout Expires on Send STR Discon Access Device SERVER, STATEFUL State Event Action New State ------------------------------------------------------------- Open Session-Timeout expires on Cleanup Idle home server Requested change: NA Proposal : ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com From owner-aaa-wg@merit.edu Sun Dec 15 03:25:53 2002 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 DAA00429 for ; Sun, 15 Dec 2002 03:25:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B4DF9125E; Sun, 15 Dec 2002 03:28:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C6069125F; Sun, 15 Dec 2002 03:28:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E01439125E for ; Sun, 15 Dec 2002 03:28:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id C7AD15E105; Sun, 15 Dec 2002 03:28:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 545FA5DDD0 for ; Sun, 15 Dec 2002 03:28:34 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBF7LWv10603 for ; Sat, 14 Dec 2002 23:21:32 -0800 Date: Sat, 14 Dec 2002 23:21:31 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG milestone revisions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Find below revised AAA WG milestones. Note that there is no penalty for finishing early. DONE Submission of AAA Transport as a Proposed Standard RFC January 03 Submission of Diameter Base as a Proposed Standard RFC February 03 Submission of Diameter NASREQ as a Proposed Standard RFC June 03 Submission of Diameter EAP as a Proposed Standard RFC Dec 03 Submission of Diameter CMS as a Proposed Standard RFC From owner-aaa-wg@merit.edu Sun Dec 15 23:14:37 2002 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 XAA15942 for ; Sun, 15 Dec 2002 23:14:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4189991207; Sun, 15 Dec 2002 23:16:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1E2691212; Sun, 15 Dec 2002 23:16:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A996391207 for ; Sun, 15 Dec 2002 23:16:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id F35805DDCD; Sun, 15 Dec 2002 23:15:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3EBD85DE14 for ; Sun, 15 Dec 2002 23:15:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBG38oK14378 for ; Sun, 15 Dec 2002 19:08:50 -0800 Date: Sun, 15 Dec 2002 19:08:50 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Request for Review of RFC 2869bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk RFC 2869 is in the process of being revised to provide clarifications and in order to address interoperability issues encountered with RADIUS/EAP. The latest version (which will appear on the IETF archive shortly) is available at: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-05.txt Comments welcome. Since a good deal of the text in the Diameter EAP application is shared with RFC 2869bis, getting RFC 2869bis squared away will contribute to completing Diameter EAP in a timely way. RFC 2869bis is a dependency of IEEE 802.1aa which is projected to be issued as an IEEE standard in Spring 2003. In order to have it issued as an RFC in time to avoid delaying IEEE 802.1aa, the plan is to bring it to IETF last call in early 2003. From owner-aaa-wg@merit.edu Mon Dec 16 04:15:21 2002 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 EAA29491 for ; Mon, 16 Dec 2002 04:15:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 322DA91216; Mon, 16 Dec 2002 04:18:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F01039121E; Mon, 16 Dec 2002 04:17:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8954E91216 for ; Mon, 16 Dec 2002 04:17:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5AF855DE7F; Mon, 16 Dec 2002 04:17:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id E56405DDB5 for ; Mon, 16 Dec 2002 04:17:56 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBG9JNt29884 for ; Mon, 16 Dec 2002 11:19:23 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Dec 2002 11:15:53 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 11:15:50 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 11:15:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Ambiguity in the description of Session-Id Date: Mon, 16 Dec 2002 11:15:49 +0200 Message-ID: Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKj7lEWVdp3rPgUSFiSwSiMeIeSgQA9VNww From: To: , Cc: X-OriginalArrivalTime: 16 Dec 2002 09:15:49.0711 (UTC) FILETIME=[B9894DF0:01C2A4E3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA29491 Hi all, The issue below seems to be reasonable - will accepting this cause any problems for anyone? John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 15 December, 2002 04:51 > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > Filed as Issue 392. > > On Fri, 13 Dec 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > > > Descriptiom of the issue: Ambiguity in Session-Id description > > Submitter name: Ghadiyaram Venkata Kishore > > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > > Date first submitted: 13 December, 2002 > > Reference: > > Document: Base > > Comment type: T > > Priority: S > > Section: > > Rationale/Explanation of issue: > > Section 8.8 describing the Session-Id AVP is ambiguous > about the mandatory part and the optional part of the > Session-Id. From the description it is possible to have a > Session-Id of the form [unique optional > value>] where there is no delimiter between the > DiameterIdentity and the remaining portion of the Session-Id. > So it is not possible to validate the correctness of the > Session-Id. It may not also be possible to specify a > delimiter as the DiameterIdentity is of type UTF8String. > > > > Is there a necessity for the mandatory part of the > Session-Id. Why should it be mandatory that the Session-Id > should start with DiameterIdentity. The whole Session-Id > could be implementation dependant and the implementation > should ensure the uniqueness. > > > > Requested Change : > > > > In section 8.8 remove the lines > > > > " The Session-Id includes a mandatory portion and an > implementation-defined portion;" > > > > and > > > > " The Session-Id MUST begin with the sender's identity > encoded in the DiameterIdentity type (see section 4.4)." > > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 13. December 2002 19:55 > > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > > > > Assuming that your question isn't answered, please file an > issue in the > > format described in: > > > > http://www.drizzle.com/~aboba/AAA/issues.html > > > > > > From owner-aaa-wg@merit.edu Mon Dec 16 04:23:33 2002 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 EAA29547 for ; Mon, 16 Dec 2002 04:23:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B0639121E; Mon, 16 Dec 2002 04:26:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C5CF91222; Mon, 16 Dec 2002 04:26:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2387D9121E for ; Mon, 16 Dec 2002 04:26:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC1FC5DF0E; Mon, 16 Dec 2002 04:26:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 0F55B5DDB5 for ; Mon, 16 Dec 2002 04:26:15 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBG9Rft07775 for ; Mon, 16 Dec 2002 11:27:41 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Dec 2002 11:19:00 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 11:18:59 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 11:18:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Suggestion to modify State Machine in base document Date: Mon, 16 Dec 2002 11:18:39 +0200 Message-ID: Thread-Topic: [AAA-WG]: Suggestion to modify State Machine in base document Thread-Index: AcKi2hTEn2wzWyijT1Cl6+DeE/tuzQCCdeZQ From: To: , Cc: X-OriginalArrivalTime: 16 Dec 2002 09:18:40.0590 (UTC) FILETIME=[1F635EE0:01C2A4E4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA29547 Hi Dilip, As the original text doesn't seem to cause any interoperability problems right now, I am not so comfortable with the suggested change. We've already long past IETF Last Call, so I think we should constrain ourselves to fixing interoperability bugs. Anyone else have an opinion? John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 13 December, 2002 19:54 > To: Dilip > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Suggestion to modify State Machine in base > document > > > Filed as issue 391. > > On Fri, 13 Dec 2002, Dilip wrote: > > > Submitter name: Dilip Patel > > Submitter email address: dilris@yahoo.com > > Document: Base > > Comment type:T > > Priority: 2 > > Section: 5.6 > > Explanation of issue: > > > > In the peer state machine. > > for the peer state Wait-Conn-Ack/Elect > > The event for which the peer is waiting is an ACK or > > NACK from the transport layer for the Intiator > > connection (I). > > In this senario a Timeout Event occuring would imply > > that the ACK/NACK event didint occur in the set time > > period. > > The current State machine requires that in this case > > action to be taken is Error and next state moved is > > Closed. > > > > The Issue is that the Responder (R) Connection has > > already been established with the peer which is > > waiting to receive a CEA on R connection. > > With the current state machine There will be no CEA > > send and that would result in a Timeout on the peers > > end (peers state on the other host). And thus closing > > of this R connection also. > > > > SUGESTION: > > ---------- > > If instead of taking a Error action and making the > > next state as CLOSED. > > The state machine could treat the Timeout as same as a > > > > I-Rcv-Conn-Nack and thus taking action R-Snd-CEA > > changing the next state to R-Open. > > > > This would establish an connection between the 2 peers > > immediately instead of waiting another few seconds > > before the 2 peers try establishing a connection > > again. > > > > Requested change: > > ---------------- > > State machine change from: > > state event action next state > > -------------------------------------------------------- > > Wait-Conn-Ack/ Timeout Error Closed > > Elect > > > > State Machine change TO: > > state event action next state > > -------------------------------------------------------- > > Wait-Conn-Ack/ Timeout R-Snd-CEA R-Open > > Elect > > > > > > > > Regards > > Dilip Patel > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com > > > > From owner-aaa-wg@merit.edu Mon Dec 16 11:15:40 2002 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 LAA09474 for ; Mon, 16 Dec 2002 11:15:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 10F4F91260; Mon, 16 Dec 2002 11:18:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77C7C91261; Mon, 16 Dec 2002 11:18:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B793491260 for ; Mon, 16 Dec 2002 11:18:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 932735DECA; Mon, 16 Dec 2002 11:18:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 1E9FE5DE85 for ; Mon, 16 Dec 2002 11:18:15 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.6/8.12.1) with ESMTP id gBGGHf6o027392; Mon, 16 Dec 2002 11:17:41 -0500 (EST) Received: from localhost (ohba@tari-dhcp162.research.telcordia.com [207.3.232.162]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA00932; Mon, 16 Dec 2002 11:18:28 -0500 (EST) Date: Mon, 16 Dec 2002 11:17:32 -0500 To: john.loughney@nokia.com Cc: aboba@internaut.com, Ext-Venkata.Ghadiyaram@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id Message-ID: <20021216161731.GA2228@catfish> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 85 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk DiameterIdentity is fqdn and thus does not seem to allow to include ";" charactor. So I don't see the ambiguity. Could you show an example case? Another issue is that how global uniqueness of Session-ID is maintained without using global unique identifier. Yoshihiro Ohba On Mon, Dec 16, 2002 at 11:15:49AM +0200, john.loughney@nokia.com wrote: > Hi all, > > The issue below seems to be reasonable - will accepting this cause > any problems for anyone? > > John > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 15 December, 2002 04:51 > > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > > > > Filed as Issue 392. > > > > On Fri, 13 Dec 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > > > > > Descriptiom of the issue: Ambiguity in Session-Id description > > > Submitter name: Ghadiyaram Venkata Kishore > > > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > > > Date first submitted: 13 December, 2002 > > > Reference: > > > Document: Base > > > Comment type: T > > > Priority: S > > > Section: > > > Rationale/Explanation of issue: > > > Section 8.8 describing the Session-Id AVP is ambiguous > > about the mandatory part and the optional part of the > > Session-Id. From the description it is possible to have a > > Session-Id of the form [unique optional > > value>] where there is no delimiter between the > > DiameterIdentity and the remaining portion of the Session-Id. > > So it is not possible to validate the correctness of the > > Session-Id. It may not also be possible to specify a > > delimiter as the DiameterIdentity is of type UTF8String. > > > > > > Is there a necessity for the mandatory part of the > > Session-Id. Why should it be mandatory that the Session-Id > > should start with DiameterIdentity. The whole Session-Id > > could be implementation dependant and the implementation > > should ensure the uniqueness. > > > > > > Requested Change : > > > > > > In section 8.8 remove the lines > > > > > > " The Session-Id includes a mandatory portion and an > > implementation-defined portion;" > > > > > > and > > > > > > " The Session-Id MUST begin with the sender's identity > > encoded in the DiameterIdentity type (see section 4.4)." > > > > > > -----Original Message----- > > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: 13. December 2002 19:55 > > > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > > > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > > > > > > > Assuming that your question isn't answered, please file an > > issue in the > > > format described in: > > > > > > http://www.drizzle.com/~aboba/AAA/issues.html > > > > > > > > > > > From owner-aaa-wg@merit.edu Mon Dec 16 12:17:32 2002 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 MAA11234 for ; Mon, 16 Dec 2002 12:17:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B54889121B; Mon, 16 Dec 2002 12:20:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8734091241; Mon, 16 Dec 2002 12:20:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F83C9121B for ; Mon, 16 Dec 2002 12:20:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 839175DF53; Mon, 16 Dec 2002 12:20:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id C747F5DF46 for ; Mon, 16 Dec 2002 12:20:16 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBGHLgt23105 for ; Mon, 16 Dec 2002 19:21:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Dec 2002 19:16:47 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 19:16:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: [AAA-WG]: Diameter messages vs. SCTP packets Date: Mon, 16 Dec 2002 19:16:47 +0200 Message-ID: <9E3407CE45911B4097632389B77B20231079CD@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKlHsr9MZLVuo+gRCSLdsOdXoYW6wABSxpA From: To: X-OriginalArrivalTime: 16 Dec 2002 17:16:47.0689 (UTC) FILETIME=[EA3B4B90:01C2A526] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The base specification and the transport profile do not mandate anything about how the Diameter messages are encapsulated in the SCTP packets. This means that a Diameter implementation must be prepared to receive all possible combinations, e.g. one Diameter message sent in multiple SCTP packets or 1.5 Diameter messages in one SCTP packets. The receiver would be greatly simplified if one of the specifications requires that a SCTP packet contains a non-fractional number of Diameter messages. Regards, Adrian From owner-aaa-wg@merit.edu Mon Dec 16 12:20:37 2002 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 MAA11368 for ; Mon, 16 Dec 2002 12:20:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A70091241; Mon, 16 Dec 2002 12:23:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A1F691264; Mon, 16 Dec 2002 12:23:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44A7691241 for ; Mon, 16 Dec 2002 12:23:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E8A35DDE3; Mon, 16 Dec 2002 12:23:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 55AF75DDB6 for ; Mon, 16 Dec 2002 12:23:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBGGFn025785; Mon, 16 Dec 2002 08:15:49 -0800 Date: Mon, 16 Dec 2002 08:15:49 -0800 (PST) From: Bernard Aboba To: Adrian.Constantin@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter messages vs. SCTP packets In-Reply-To: <9E3407CE45911B4097632389B77B20231079CD@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The receiver would be greatly simplified if one of the specifications > requires that a SCTP packet contains a non-fractional number of Diameter > messages. I don't see how this could be required -- Diameter is assumed to run over a stream socket, so that the packetization of the underlying reliable transport is not under the control of the Diameter application. From owner-aaa-wg@merit.edu Mon Dec 16 12:34:54 2002 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 MAA11648 for ; Mon, 16 Dec 2002 12:34:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2A0691264; Mon, 16 Dec 2002 12:37:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A44FE91266; Mon, 16 Dec 2002 12:37:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC9A791264 for ; Mon, 16 Dec 2002 12:37:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 90C615DEBF; Mon, 16 Dec 2002 12:37:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 566D95DDE3 for ; Mon, 16 Dec 2002 12:37:33 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBGHam009831 for ; Mon, 16 Dec 2002 19:36:48 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Dec 2002 19:37:32 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 19:37:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Date: Mon, 16 Dec 2002 19:37:31 +0200 Message-ID: <9E3407CE45911B4097632389B77B2023C85272@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter messages vs. SCTP packets Thread-Index: AcKlKMTERTve77T0SeqMyOXbeS+ehAAACE9w From: To: Cc: X-OriginalArrivalTime: 16 Dec 2002 17:37:32.0112 (UTC) FILETIME=[CFF72D00:01C2A529] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11648 SCTP reassembles the packets at the destination and delivers them to the application exactly how they were sent. The streaming part of SCTP does not refer to the way the packets are constructed. From encapsulation point of view SCTP resembles more to UDP then to TCP. Adrian -----Original Message----- From: ext Bernard Aboba [mailto:aboba@internaut.com] Sent: 16 December, 2002 18:16 To: Constantin Adrian (NET/Helsinki) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter messages vs. SCTP packets > The receiver would be greatly simplified if one of the specifications > requires that a SCTP packet contains a non-fractional number of Diameter > messages. I don't see how this could be required -- Diameter is assumed to run over a stream socket, so that the packetization of the underlying reliable transport is not under the control of the Diameter application. From owner-aaa-wg@merit.edu Mon Dec 16 12:47:10 2002 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 MAA11945 for ; Mon, 16 Dec 2002 12:47:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F9B591266; Mon, 16 Dec 2002 12:49:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3360391267; Mon, 16 Dec 2002 12:49:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3995E91266 for ; Mon, 16 Dec 2002 12:49:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 14E535DF7B; Mon, 16 Dec 2002 12:49:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id EAE775DEB4 for ; Mon, 16 Dec 2002 12:49:53 -0500 (EST) Received: (qmail 1147 invoked by uid 500); 16 Dec 2002 17:49:52 -0000 Date: Mon, 16 Dec 2002 11:49:51 -0600 From: David Frascone To: Adrian.Constantin@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter messages vs. SCTP packets Message-ID: <20021216174951.GA534@newman.frascone.com> Mail-Followup-To: Adrian.Constantin@nokia.com, aboba@internaut.com, aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B2023C85272@esebe014.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E3407CE45911B4097632389B77B2023C85272@esebe014.ntc.nokia.com> User-Agent: Mutt/1.5.1i Sender: owner-aaa-wg@merit.edu Precedence: bulk I was under the impression that a single diameter message would be sent in a single SCTP packet. Perhaps a single line makeing that obvious should be added. -Dave On Monday, 16 Dec 2002, Adrian.Constantin@nokia.com wrote: > SCTP reassembles the packets at the destination and delivers them to the application exactly how they were sent. The streaming part of SCTP does not refer to the way the packets are constructed. From encapsulation point of view SCTP resembles more to UDP then to TCP. > > Adrian > > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 16 December, 2002 18:16 > To: Constantin Adrian (NET/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Diameter messages vs. SCTP packets > > > > The receiver would be greatly simplified if one of the specifications > > requires that a SCTP packet contains a non-fractional number of Diameter > > messages. > > I don't see how this could be required -- Diameter is assumed to run over > a stream socket, so that the packetization of the underlying reliable > transport is not under the control of the Diameter application. > -- David Frascone I like to reminisce with people I don't know. From owner-aaa-wg@merit.edu Mon Dec 16 12:51:24 2002 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 MAA12029 for ; Mon, 16 Dec 2002 12:51:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F62F91267; Mon, 16 Dec 2002 12:54:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D0B791268; Mon, 16 Dec 2002 12:54:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3087291267 for ; Mon, 16 Dec 2002 12:54:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1EC325DF85; Mon, 16 Dec 2002 12:54:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 0501D5DF82 for ; Mon, 16 Dec 2002 12:54:08 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBGHtYt08752 for ; Mon, 16 Dec 2002 19:55:34 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Dec 2002 19:52:27 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 19:52:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Ambiguity in the description of Session-Id Date: Mon, 16 Dec 2002 19:52:27 +0200 Message-ID: <9E3407CE45911B4097632389B77B20230187026B@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKlHr7prG+n55ZSRgSDQdfspdJSXgAAINtA From: To: Cc: , , X-OriginalArrivalTime: 16 Dec 2002 17:52:27.0725 (UTC) FILETIME=[E5CADFD0:01C2A52B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit DiameterIdentity is fqdn and thus does not seem to allow to include ";" charactor. So I don't see the ambiguity. Could you show an example case? [Kishore] The problem occurs once domain names are internationalized. If we use ';' as the delimiter then we restrict ourselves using ASCII names for fqdn and Diameter host identities. Secondly present base protocol specification does not mandate that a ';'(or any other delimiter) MUST follow the DiameterIdentity in Session-Id. Another issue is that how global uniqueness of Session-ID is maintained without using global unique identifier. [Kishore]I do not understand why a globally unique identifier has to be specified by the protocol to generate a globally unique Session-Id. One can use any globally unique identifer (even a DiameterIdentity of the entity generating the Sesion-Id) within the Session-Id but that need not be specified in the protocol. For example one can place the DiameterIdentity both at the start or at the end of the Session-Id but still can ensure the uniqueness. Kishore -----Original Message----- From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: 16. December 2002 18:18 To: Loughney John (NRC/Helsinki) Cc: aboba@internaut.com; Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki); aaa-wg@merit.edu Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id DiameterIdentity is fqdn and thus does not seem to allow to include ";" charactor. So I don't see the ambiguity. Could you show an example case? Another issue is that how global uniqueness of Session-ID is maintained without using global unique identifier. Yoshihiro Ohba On Mon, Dec 16, 2002 at 11:15:49AM +0200, john.loughney@nokia.com wrote: > Hi all, > > The issue below seems to be reasonable - will accepting this cause > any problems for anyone? > > John > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 15 December, 2002 04:51 > > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > > > > Filed as Issue 392. > > > > On Fri, 13 Dec 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > > > > > Descriptiom of the issue: Ambiguity in Session-Id description > > > Submitter name: Ghadiyaram Venkata Kishore > > > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > > > Date first submitted: 13 December, 2002 > > > Reference: > > > Document: Base > > > Comment type: T > > > Priority: S > > > Section: > > > Rationale/Explanation of issue: > > > Section 8.8 describing the Session-Id AVP is ambiguous > > about the mandatory part and the optional part of the > > Session-Id. From the description it is possible to have a > > Session-Id of the form [unique optional > > value>] where there is no delimiter between the > > DiameterIdentity and the remaining portion of the Session-Id. > > So it is not possible to validate the correctness of the > > Session-Id. It may not also be possible to specify a > > delimiter as the DiameterIdentity is of type UTF8String. > > > > > > Is there a necessity for the mandatory part of the > > Session-Id. Why should it be mandatory that the Session-Id > > should start with DiameterIdentity. The whole Session-Id > > could be implementation dependant and the implementation > > should ensure the uniqueness. > > > > > > Requested Change : > > > > > > In section 8.8 remove the lines > > > > > > " The Session-Id includes a mandatory portion and an > > implementation-defined portion;" > > > > > > and > > > > > > " The Session-Id MUST begin with the sender's identity > > encoded in the DiameterIdentity type (see section 4.4)." > > > > > > -----Original Message----- > > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: 13. December 2002 19:55 > > > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > > > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > > > > > > > Assuming that your question isn't answered, please file an > > issue in the > > > format described in: > > > > > > http://www.drizzle.com/~aboba/AAA/issues.html > > > > > > > > > > > From owner-aaa-wg@merit.edu Mon Dec 16 12:55:11 2002 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 MAA12200 for ; Mon, 16 Dec 2002 12:55:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58AAB91268; Mon, 16 Dec 2002 12:57:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E36891269; Mon, 16 Dec 2002 12:57:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32A0F91268 for ; Mon, 16 Dec 2002 12:57:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 210585DFA3; Mon, 16 Dec 2002 12:57:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 944CD5DFA2 for ; Mon, 16 Dec 2002 12:57:54 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBGGoRi27716; Mon, 16 Dec 2002 08:50:27 -0800 Date: Mon, 16 Dec 2002 08:50:27 -0800 (PST) From: Bernard Aboba To: David Frascone Cc: Adrian.Constantin@nokia.com, Subject: Re: [AAA-WG]: Diameter messages vs. SCTP packets In-Reply-To: <20021216174951.GA534@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk What if the Diameter message is too big?? On Mon, 16 Dec 2002, David Frascone wrote: > I was under the impression that a single diameter message would be sent in a > single SCTP packet. Perhaps a single line makeing that obvious should be > added. > > -Dave From owner-aaa-wg@merit.edu Mon Dec 16 13:15:22 2002 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 NAA12839 for ; Mon, 16 Dec 2002 13:15:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 824C19120F; Mon, 16 Dec 2002 13:18:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E1999126A; Mon, 16 Dec 2002 13:18:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EAEB39120F for ; Mon, 16 Dec 2002 13:18:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id D51165DFA2; Mon, 16 Dec 2002 13:18:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web80213.mail.yahoo.com (web80213.mail.yahoo.com [66.218.79.48]) by segue.merit.edu (Postfix) with SMTP id 5363F5DF85 for ; Mon, 16 Dec 2002 13:18:00 -0500 (EST) Message-ID: <20021216181754.96777.qmail@web80213.mail.yahoo.com> Received: from [128.251.168.94] by web80213.mail.yahoo.com via HTTP; Mon, 16 Dec 2002 10:17:54 PST Date: Mon, 16 Dec 2002 10:17:54 -0800 (PST) From: Behcet Sarikaya Reply-To: sarikaya@ieee.org Subject: Re: [AAA-WG]: Re: draft-ietf-aaa-diameter-mobileip-13.txt To: aaa-wg@merit.edu In-Reply-To: <20021212035454.16620.qmail@web80107.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Description of issue Submitter name: Behcet Sarikaya Submitter email address: sarikaya@ieee.org Date first submitted: 12/16/02 Reference: Document: mobileip Comment type: 'T' Priority: '1' Should fix Section: 1.3 Rationale/Explanation of issue: How to keep Acct-Multi-Session-Id unique if dynamic HA assignment is used? Length description of problem the HA generates a unique > Acct-Multi-Session-Id when receiving an HAR for a > new session, and > returns this same value in every HAA for the > session. This Acct- > Multi-Session-Id AVP will be returned to the > foreign agent by the > AAAH in the AMA. Both the foreign and home agents > MUST include the > Acct-Multi-Session-Id in the accounting messages. > > My question is if HA is dynamically allocated and > is constantly changing, how can we assure > Acct-Multi-Session-Id is > going to stay the same? Requested change: Proposal Maybe transfer Acct-Multi-Session-Id to new HA From owner-aaa-wg@merit.edu Mon Dec 16 14:42:43 2002 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 OAA15379 for ; Mon, 16 Dec 2002 14:42:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7FB6991245; Mon, 16 Dec 2002 14:43:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B4429126B; Mon, 16 Dec 2002 14:43:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B47491245 for ; Mon, 16 Dec 2002 14:43:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3858F5DDA6; Mon, 16 Dec 2002 14:43:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id BC2D15DD90 for ; Mon, 16 Dec 2002 14:43:52 -0500 (EST) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.6/8.12.1) with ESMTP id gBGJhO6o011568; Mon, 16 Dec 2002 14:43:30 -0500 (EST) Received: from localhost (ohba@tari-dhcp162.research.telcordia.com [207.3.232.162]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA01462; Mon, 16 Dec 2002 14:44:12 -0500 (EST) Date: Mon, 16 Dec 2002 14:43:22 -0500 To: Ext-Venkata.Ghadiyaram@nokia.com Cc: yohba@tari.toshiba.com, aboba@internaut.com, aaa-wg@merit.edu, john.loughney@nokia.com Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id Message-ID: <20021216194322.GD2228@catfish> References: <9E3407CE45911B4097632389B77B20230187026B@esebe014.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <9E3407CE45911B4097632389B77B20230187026B@esebe014.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20021213(IM143) Lines: 125 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Dec 16, 2002 at 07:52:27PM +0200, Ext-Venkata.Ghadiyaram@nokia.com wrote: > DiameterIdentity is fqdn and thus does not seem to allow to include > ";" charactor. So I don't see the ambiguity. Could you show an > example case? > [Kishore] The problem occurs once domain names are internationalized. If we use ';' as the delimiter then we restrict ourselves using ASCII names for fqdn and Diameter host identities. Secondly present base protocol specification does not mandate that a ';'(or any other delimiter) MUST follow the DiameterIdentity in Session-Id. > If internationalized domain name is the issue, I think we should use a delimiter that is not allowed to be included in stringprep. If ";" is allowed to be included in stringprep, then it might be better to choose other delimiter. > Another issue is that how global uniqueness of Session-ID is > maintained without using global unique identifier. > > [Kishore]I do not understand why a globally unique identifier has to be specified by the protocol to generate a globally unique Session-Id. One can use any globally unique identifer (even a DiameterIdentity of the entity generating the Sesion-Id) within the Session-Id but that need not be specified in the protocol. For example one can place the DiameterIdentity both at the start or at the end of the Session-Id but still can ensure the uniqueness. I don't think using any globally unique identifer can guarantee global uniqueness. If one uses value X from global identifier space S1 and the other uses value Y from other global identifier S2, it is possible that X==Y if intersection of S1 and S2 are not null. So, a protocol must define what global space is used in order to guarantee the uniqueness of identifier. Yoshihiro Ohba > > Kishore > > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 16. December 2002 18:18 > To: Loughney John (NRC/Helsinki) > Cc: aboba@internaut.com; Ghadiyaram Venkata > (EXT-TataConsultancy/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > DiameterIdentity is fqdn and thus does not seem to allow to include > ";" charactor. So I don't see the ambiguity. Could you show an > example case? > > Another issue is that how global uniqueness of Session-ID is > maintained without using global unique identifier. > > Yoshihiro Ohba > > > On Mon, Dec 16, 2002 at 11:15:49AM +0200, john.loughney@nokia.com wrote: > > Hi all, > > > > The issue below seems to be reasonable - will accepting this cause > > any problems for anyone? > > > > John > > > > > -----Original Message----- > > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: 15 December, 2002 04:51 > > > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > > > Cc: aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > > > > > > > Filed as Issue 392. > > > > > > On Fri, 13 Dec 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > > > > > > > Descriptiom of the issue: Ambiguity in Session-Id description > > > > Submitter name: Ghadiyaram Venkata Kishore > > > > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > > > > Date first submitted: 13 December, 2002 > > > > Reference: > > > > Document: Base > > > > Comment type: T > > > > Priority: S > > > > Section: > > > > Rationale/Explanation of issue: > > > > Section 8.8 describing the Session-Id AVP is ambiguous > > > about the mandatory part and the optional part of the > > > Session-Id. From the description it is possible to have a > > > Session-Id of the form [unique optional > > > value>] where there is no delimiter between the > > > DiameterIdentity and the remaining portion of the Session-Id. > > > So it is not possible to validate the correctness of the > > > Session-Id. It may not also be possible to specify a > > > delimiter as the DiameterIdentity is of type UTF8String. > > > > > > > > Is there a necessity for the mandatory part of the > > > Session-Id. Why should it be mandatory that the Session-Id > > > should start with DiameterIdentity. The whole Session-Id > > > could be implementation dependant and the implementation > > > should ensure the uniqueness. > > > > > > > > Requested Change : > > > > > > > > In section 8.8 remove the lines > > > > > > > > " The Session-Id includes a mandatory portion and an > > > implementation-defined portion;" > > > > > > > > and > > > > > > > > " The Session-Id MUST begin with the sender's identity > > > encoded in the DiameterIdentity type (see section 4.4)." > > > > > > > > -----Original Message----- > > > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > > > Sent: 13. December 2002 19:55 > > > > To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) > > > > Subject: Re: [AAA-WG]: Ambiguity in the description of Session-Id > > > > > > > > > > > > Assuming that your question isn't answered, please file an > > > issue in the > > > > format described in: > > > > > > > > http://www.drizzle.com/~aboba/AAA/issues.html > > > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Dec 17 00:04:51 2002 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 AAA26487 for ; Tue, 17 Dec 2002 00:04:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA6DC91288; Tue, 17 Dec 2002 00:07:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71DAC9128B; Tue, 17 Dec 2002 00:07:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A03791288 for ; Tue, 17 Dec 2002 00:07:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D9ED5DE17; Tue, 17 Dec 2002 00:07:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 58B7D5DDB1 for ; Tue, 17 Dec 2002 00:07:35 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH591t24419 for ; Tue, 17 Dec 2002 07:09:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Dec 2002 07:07:34 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 07:07:33 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 07:07:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Date: Tue, 17 Dec 2002 07:07:32 +0200 Message-ID: Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKlHsr9MZLVuo+gRCSLdsOdXoYW6wABSxpAABlXZUA= From: To: , X-OriginalArrivalTime: 17 Dec 2002 05:07:33.0682 (UTC) FILETIME=[35396920:01C2A58A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Adrian, > The base specification and the transport profile do not > mandate anything about how the Diameter messages are > encapsulated in the SCTP packets. This is dependent upon the SCTP implementation. Many SCTP implementations will be using sockets, see: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-05.txt for details. > This means that a Diameter > implementation must be prepared to receive all possible > combinations, e.g. one Diameter message sent in multiple SCTP > packets or 1.5 Diameter messages in one SCTP packets. > > The receiver would be greatly simplified if one of the > specifications requires that a SCTP packet contains a > non-fractional number of Diameter messages. SCTP will present a fully formed Diameter packet to the Diameter level, this will be no different than with TCP. There is nothing more that is needed in Base or transport document more that is needed. John From owner-aaa-wg@merit.edu Tue Dec 17 00:13:33 2002 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 AAA26640 for ; Tue, 17 Dec 2002 00:13:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B49B9128B; Tue, 17 Dec 2002 00:15:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08BA99128C; Tue, 17 Dec 2002 00:15:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E31629128B for ; Tue, 17 Dec 2002 00:15:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0D58E5DF8E; Tue, 17 Dec 2002 00:15:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id BD95E5DE93 for ; Tue, 17 Dec 2002 00:15:29 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH5Eh026648 for ; Tue, 17 Dec 2002 07:14:43 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Dec 2002 07:15:27 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 07:15:27 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 07:15:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Date: Tue, 17 Dec 2002 07:15:27 +0200 Message-ID: Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKlHsr9MZLVuo+gRCSLdsOdXoYW6wABSxpAABnRjQA= From: To: , X-OriginalArrivalTime: 17 Dec 2002 05:15:27.0578 (UTC) FILETIME=[4FB033A0:01C2A58B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, One more note - SCTP supports user data up to 64k. I hope that Diameter messages are not that long .... > -----Original Message----- > From: ext [mailto:Adrian.Constantin@nokia.com] > Sent: 16 December, 2002 19:17 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter messages vs. SCTP packets > > > Hi, > > The base specification and the transport profile do not > mandate anything about how the Diameter messages are > encapsulated in the SCTP packets. This means that a Diameter > implementation must be prepared to receive all possible > combinations, e.g. one Diameter message sent in multiple SCTP > packets or 1.5 Diameter messages in one SCTP packets. > > The receiver would be greatly simplified if one of the > specifications requires that a SCTP packet contains a > non-fractional number of Diameter messages. > > Regards, > > Adrian > From owner-aaa-wg@merit.edu Tue Dec 17 00:16:35 2002 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 AAA26726 for ; Tue, 17 Dec 2002 00:16:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E76F9128C; Tue, 17 Dec 2002 00:19:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09EC19128D; Tue, 17 Dec 2002 00:19:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 025CD9128C for ; Tue, 17 Dec 2002 00:19:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3DAC5DE93; Tue, 17 Dec 2002 00:19:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id EDE0A5DE15 for ; Tue, 17 Dec 2002 00:19:18 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH5IX027649 for ; Tue, 17 Dec 2002 07:18:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Dec 2002 07:16:56 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 07:16:54 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 07:16:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Ambiguity in the description of Session-Id Date: Tue, 17 Dec 2002 07:16:53 +0200 Message-ID: Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKlO5R/Fhn6uWQbQwCiXbS3f8E3xQAT8s3Q From: To: , Cc: , X-OriginalArrivalTime: 17 Dec 2002 05:16:53.0584 (UTC) FILETIME=[82F3AD00:01C2A58B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, > On Mon, Dec 16, 2002 at 07:52:27PM +0200, > Ext-Venkata.Ghadiyaram@nokia.com wrote: > > DiameterIdentity is fqdn and thus does not seem to allow to include > > ";" charactor. So I don't see the ambiguity. Could you show an > > example case? > > [Kishore] The problem occurs once domain names are > internationalized. If we use ';' as the delimiter then we > restrict ourselves using ASCII names for fqdn and Diameter > host identities. Secondly present base protocol > specification does not mandate that a ';'(or any other > delimiter) MUST follow the DiameterIdentity in Session-Id. > > > > If internationalized domain name is the issue, I think we should use a > delimiter that is not allowed to be included in stringprep. If ";" is > allowed to be included in stringprep, then it might be better to > choose other delimiter. I've discussed this with the concerned IESG member, Internationalization should not be an issue with Diameter. A good compromise would be to support ":" as the delimeter. I will make the change. John From owner-aaa-wg@merit.edu Tue Dec 17 03:38:57 2002 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 DAA09309 for ; Tue, 17 Dec 2002 03:38:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C34B791220; Tue, 17 Dec 2002 03:41:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 726D39128F; Tue, 17 Dec 2002 03:41:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2537891220 for ; Tue, 17 Dec 2002 03:41:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 115E65DE61; Tue, 17 Dec 2002 03:41:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 1AE775DE26 for ; Tue, 17 Dec 2002 03:41:37 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH8h3t14675 for ; Tue, 17 Dec 2002 10:43:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Dec 2002 10:35:58 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 10:35:57 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 10:35:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Ambiguity in the description of Session-Id Date: Tue, 17 Dec 2002 10:35:56 +0200 Message-ID: Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKj7lEWVdp3rPgUSFiSwSiMeIeSgQBuKoUw From: To: Cc: X-OriginalArrivalTime: 17 Dec 2002 08:35:57.0051 (UTC) FILETIME=[51D01CB0:01C2A5A7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA09309 Hi all, Further clarification, section 8.8 includes this definition: ;;[;] and this example: accesspoint7.acme.com;1876543210;523 So clearly, the semicolon ";" is being used at the delimiter, and is specified in the text already. So, I think that this is a non-issue. Just to be precise, I have modified the 3rd paragraph, to say: The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see section 4.4). The remainder of the Session-Id is delimted by a ";" charcter, and MAY be any sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element): And therefore we can close this issue. John From owner-aaa-wg@merit.edu Tue Dec 17 03:40:46 2002 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 DAA09365 for ; Tue, 17 Dec 2002 03:40:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CB3319128F; Tue, 17 Dec 2002 03:43:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C99791290; Tue, 17 Dec 2002 03:43:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76BE39128F for ; Tue, 17 Dec 2002 03:43:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 685E55DE26; Tue, 17 Dec 2002 03:43:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id AD0675DDA3 for ; Tue, 17 Dec 2002 03:43:25 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH8iqt17441 for ; Tue, 17 Dec 2002 10:44:52 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Dec 2002 10:43:07 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 10:43:06 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 10:43:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Date: Tue, 17 Dec 2002 10:43:06 +0200 Message-ID: Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKlHsr9MZLVuo+gRCSLdsOdXoYW6wABSxpAACDZrCA= From: To: , X-OriginalArrivalTime: 17 Dec 2002 08:43:06.0354 (UTC) FILETIME=[51B28D20:01C2A5A8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Adrian, One further comment. SCTP provides fragmentation & re-assembly services for the upper layer protocol. From 2960: 1.3.3 User Data Fragmentation When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. So I don't think we need to worry about your concerns. More interesting SCTP reading can be found here (disclaimer - I am a co-auther of 3257). Stream Control Transmission Protocol Applicability Statement (RFC 3257) http://www.ietf.org/rfc/rfc3257.txt br, John > -----Original Message----- > From: ext [mailto:Adrian.Constantin@nokia.com] > Sent: 16 December, 2002 19:17 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter messages vs. SCTP packets > > > Hi, > > The base specification and the transport profile do not > mandate anything about how the Diameter messages are > encapsulated in the SCTP packets. This means that a Diameter > implementation must be prepared to receive all possible > combinations, e.g. one Diameter message sent in multiple SCTP > packets or 1.5 Diameter messages in one SCTP packets. > > The receiver would be greatly simplified if one of the > specifications requires that a SCTP packet contains a > non-fractional number of Diameter messages. > > Regards, > > Adrian > From owner-aaa-wg@merit.edu Tue Dec 17 03:49:09 2002 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 DAA09486 for ; Tue, 17 Dec 2002 03:49:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B72091290; Tue, 17 Dec 2002 03:51:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58FF191292; Tue, 17 Dec 2002 03:51:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38C4491290 for ; Tue, 17 Dec 2002 03:51:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 132955DDB1; Tue, 17 Dec 2002 03:51:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 2AC025DDA3 for ; Tue, 17 Dec 2002 03:51:55 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH8rIt25274 for ; Tue, 17 Dec 2002 10:53:18 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Dec 2002 10:51:50 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 10:51:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Ambiguity in the description of Session-Id Date: Tue, 17 Dec 2002 10:51:48 +0200 Message-ID: <9E3407CE45911B4097632389B77B20230187026C@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Ambiguity in the description of Session-Id Thread-Index: AcKj7lEWVdp3rPgUSFiSwSiMeIeSgQBuKoUwAABORcA= From: To: Cc: X-OriginalArrivalTime: 17 Dec 2002 08:51:48.0598 (UTC) FILETIME=[88FAA960:01C2A5A9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA09486 Hi, I agree with the modified text (except that the word "character" is wrongly spelt in the text). In the old text ";" is used as a delimiter in the examples and the recommended format of a Session-Id, but the only mandatory part is that the Sesion-Id should start with DiameterIdentity. Kishore -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: 17. December 2002 10:36 To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Ambiguity in the description of Session-Id Hi all, Further clarification, section 8.8 includes this definition: ;;[;] and this example: accesspoint7.acme.com;1876543210;523 So clearly, the semicolon ";" is being used at the delimiter, and is specified in the text already. So, I think that this is a non-issue. Just to be precise, I have modified the 3rd paragraph, to say: The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see section 4.4). The remainder of the Session-Id is delimted by a ";" charcter, and MAY be any sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element): And therefore we can close this issue. John From owner-aaa-wg@merit.edu Tue Dec 17 04:05:45 2002 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 EAA09837 for ; Tue, 17 Dec 2002 04:05:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 051AB91292; Tue, 17 Dec 2002 04:08:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C84B991294; Tue, 17 Dec 2002 04:08:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A817C91292 for ; Tue, 17 Dec 2002 04:08:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 85DE85DE15; Tue, 17 Dec 2002 04:08:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hindon.hss.co.in (unknown [202.54.26.202]) by segue.merit.edu (Postfix) with ESMTP id 9F71F5DDA3 for ; Tue, 17 Dec 2002 04:08:28 -0500 (EST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gBH97Vr21916 for ; Tue, 17 Dec 2002 14:37:32 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gBH97R821899 for ; Tue, 17 Dec 2002 14:37:27 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gBH99Mn07205 for ; Tue, 17 Dec 2002 14:39:22 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C92.0031949C ; Tue, 17 Dec 2002 14:31:33 +0530 X-Lotus-FromDomain: HSS From: akbansal@hss.hns.com To: aaa-wg@merit.edu Message-ID: <65256C92.00319426.00@sandesh.hss.hns.com> Date: Tue, 17 Dec 2002 14:29:11 +0530 Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi section 6.9 of 2960 says "Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the re-assembly of the message, it should dispatch part of its inbound message through a partial delivery API (see Section 10), freeing some of its receive buffer space so that the rest of the message may be received." section 3.1.4 of draft-ietf-tsvwg-sctpsocket-05.txt says: "If the SCTP stack is running low on buffers, it may partially deliver a message. In this case, MSG_EOR will not be set, and more calls to recvmsg() will be necessary to completely consume the message. Only one message at a time can be partially delivered." Doesn't it mean that one Diameter message may arrive in multiple SCTP packets to the Diameter implementation? Regards -Ankit john.loughney@nokia.com on 12/17/2002 02:13:06 PM To: Adrian.Constantin@nokia.com, aaa-wg@merit.edu cc: (bcc: Ankit Bansal/HSS) Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Adrian, One further comment. SCTP provides fragmentation & re-assembly services for the upper layer protocol. From 2960: 1.3.3 User Data Fragmentation When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. So I don't think we need to worry about your concerns. More interesting SCTP reading can be found here (disclaimer - I am a co-auther of 3257). Stream Control Transmission Protocol Applicability Statement (RFC 3257) http://www.ietf.org/rfc/rfc3257.txt br, John > -----Original Message----- > From: ext [mailto:Adrian.Constantin@nokia.com] > Sent: 16 December, 2002 19:17 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter messages vs. SCTP packets > > > Hi, > > The base specification and the transport profile do not > mandate anything about how the Diameter messages are > encapsulated in the SCTP packets. This means that a Diameter > implementation must be prepared to receive all possible > combinations, e.g. one Diameter message sent in multiple SCTP > packets or 1.5 Diameter messages in one SCTP packets. > > The receiver would be greatly simplified if one of the > specifications requires that a SCTP packet contains a > non-fractional number of Diameter messages. > > Regards, > > Adrian > From owner-aaa-wg@merit.edu Tue Dec 17 04:20:58 2002 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 EAA10085 for ; Tue, 17 Dec 2002 04:20:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 013F391294; Tue, 17 Dec 2002 04:23:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAD2C91295; Tue, 17 Dec 2002 04:23:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8EAE291294 for ; Tue, 17 Dec 2002 04:23:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 722A25DDF8; Tue, 17 Dec 2002 04:23:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B185A5DDA3 for ; Tue, 17 Dec 2002 04:23:43 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH9PAt20403 for ; Tue, 17 Dec 2002 11:25:10 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Dec 2002 11:23:36 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 11:23:34 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 11:23:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Date: Tue, 17 Dec 2002 11:23:33 +0200 Message-ID: Thread-Topic: [AAA-WG]: Diameter messages vs. SCTP packets Thread-Index: AcKlrQQ1ZmWWepdcRaCAufiqJcUn8QAANHZQ From: To: , X-OriginalArrivalTime: 17 Dec 2002 09:23:34.0159 (UTC) FILETIME=[F8C831F0:01C2A5AD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA10085 Hi Ankit, These are implementation issues. Partial Delivery is a MAY, meaning one cannot assume that it is implemented. How large will Diameter messages be? I don't expect them to be very large .. John > -----Original Message----- > From: ext akbansal@hss.hns.com [mailto:akbansal@hss.hns.com] > Sent: 17 December, 2002 10:59 > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets > > > > > > Hi > > section 6.9 of 2960 says > > "Note: If the data receiver runs out of buffer space while > still waiting for > more fragments to complete the re-assembly of the message, > it should dispatch > part of its inbound message through a partial delivery API > (see Section 10), > freeing some of its receive buffer space so that the rest > of the message may > be received." > > section 3.1.4 of draft-ietf-tsvwg-sctpsocket-05.txt says: > > "If the SCTP stack is running low on buffers, it may > partially deliver a > message. In this case, MSG_EOR will not be set, and more > calls to recvmsg() > will be necessary to completely consume the message. Only > one message at a > time can be partially delivered." > > Doesn't it mean that one Diameter message may arrive in > multiple SCTP packets to > the Diameter implementation? > > Regards > -Ankit > > > > > > john.loughney@nokia.com on 12/17/2002 02:13:06 PM > > To: Adrian.Constantin@nokia.com, aaa-wg@merit.edu > cc: (bcc: Ankit Bansal/HSS) > > Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets > > > > > Adrian, > > One further comment. SCTP provides fragmentation & > re-assembly services > for the upper layer protocol. From 2960: > > 1.3.3 User Data Fragmentation > > When needed, SCTP fragments user messages to ensure that the SCTP > packet passed to the lower layer conforms to the path MTU. On > receipt, fragments are reassembled into complete messages before > being passed to the SCTP user. > > So I don't think we need to worry about your concerns. > > More interesting SCTP reading can be found here (disclaimer - I am a > co-auther of 3257). > > Stream Control Transmission Protocol Applicability Statement > (RFC 3257) > http://www.ietf.org/rfc/rfc3257.txt > > br, > John > > > -----Original Message----- > > From: ext [mailto:Adrian.Constantin@nokia.com] > > Sent: 16 December, 2002 19:17 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Diameter messages vs. SCTP packets > > > > > > Hi, > > > > The base specification and the transport profile do not > > mandate anything about how the Diameter messages are > > encapsulated in the SCTP packets. This means that a Diameter > > implementation must be prepared to receive all possible > > combinations, e.g. one Diameter message sent in multiple SCTP > > packets or 1.5 Diameter messages in one SCTP packets. > > > > The receiver would be greatly simplified if one of the > > specifications requires that a SCTP packet contains a > > non-fractional number of Diameter messages. > > > > Regards, > > > > Adrian > > > > > > > From owner-aaa-wg@merit.edu Tue Dec 17 04:45:58 2002 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 EAA10342 for ; Tue, 17 Dec 2002 04:45:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 751A491295; Tue, 17 Dec 2002 04:48:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44AF091296; Tue, 17 Dec 2002 04:48:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E21391295 for ; Tue, 17 Dec 2002 04:48:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id E7B895DD8F; Tue, 17 Dec 2002 04:48:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 094485DDA3 for ; Tue, 17 Dec 2002 04:48:42 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH9lu010356 for ; Tue, 17 Dec 2002 11:47:56 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Dec 2002 11:45:29 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 11:45:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Date: Tue, 17 Dec 2002 11:45:28 +0200 Message-ID: <9E3407CE45911B4097632389B77B2023017DFAB2@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter messages vs. SCTP packets Thread-Index: AcKlrQQzougKQR5YRI6pMeTAbvM2qgAA6mLw From: To: , X-OriginalArrivalTime: 17 Dec 2002 09:45:28.0777 (UTC) FILETIME=[085AFB90:01C2A5B1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA10342 Hi Ankit, Even if Diameter messages arrive in multiple packets, how does it require any change to the Diameter specicication. Is this not an implementation issue? - Kishore -----Original Message----- From: ext akbansal@hss.hns.com [mailto:akbansal@hss.hns.com] Sent: 17. December 2002 10:59 To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Hi section 6.9 of 2960 says "Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the re-assembly of the message, it should dispatch part of its inbound message through a partial delivery API (see Section 10), freeing some of its receive buffer space so that the rest of the message may be received." section 3.1.4 of draft-ietf-tsvwg-sctpsocket-05.txt says: "If the SCTP stack is running low on buffers, it may partially deliver a message. In this case, MSG_EOR will not be set, and more calls to recvmsg() will be necessary to completely consume the message. Only one message at a time can be partially delivered." Doesn't it mean that one Diameter message may arrive in multiple SCTP packets to the Diameter implementation? Regards -Ankit john.loughney@nokia.com on 12/17/2002 02:13:06 PM To: Adrian.Constantin@nokia.com, aaa-wg@merit.edu cc: (bcc: Ankit Bansal/HSS) Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Adrian, One further comment. SCTP provides fragmentation & re-assembly services for the upper layer protocol. From 2960: 1.3.3 User Data Fragmentation When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. So I don't think we need to worry about your concerns. More interesting SCTP reading can be found here (disclaimer - I am a co-auther of 3257). Stream Control Transmission Protocol Applicability Statement (RFC 3257) http://www.ietf.org/rfc/rfc3257.txt br, John > -----Original Message----- > From: ext [mailto:Adrian.Constantin@nokia.com] > Sent: 16 December, 2002 19:17 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter messages vs. SCTP packets > > > Hi, > > The base specification and the transport profile do not > mandate anything about how the Diameter messages are > encapsulated in the SCTP packets. This means that a Diameter > implementation must be prepared to receive all possible > combinations, e.g. one Diameter message sent in multiple SCTP > packets or 1.5 Diameter messages in one SCTP packets. > > The receiver would be greatly simplified if one of the > specifications requires that a SCTP packet contains a > non-fractional number of Diameter messages. > > Regards, > > Adrian > From owner-aaa-wg@merit.edu Tue Dec 17 04:55:31 2002 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 EAA10509 for ; Tue, 17 Dec 2002 04:55:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3FE3091296; Tue, 17 Dec 2002 04:58:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B67291297; Tue, 17 Dec 2002 04:58:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D93E291296 for ; Tue, 17 Dec 2002 04:58:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id C30BF5DE4A; Tue, 17 Dec 2002 04:58:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hindon.hss.co.in (unknown [202.54.26.202]) by segue.merit.edu (Postfix) with ESMTP id 403C95DE1B for ; Tue, 17 Dec 2002 04:58:08 -0500 (EST) Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gBH9vBr01511 for ; Tue, 17 Dec 2002 15:27:11 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gBH9vA801507; Tue, 17 Dec 2002 15:27:10 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gBH9x5M11193; Tue, 17 Dec 2002 15:29:05 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C92.003621D9 ; Tue, 17 Dec 2002 15:21:16 +0530 X-Lotus-FromDomain: HSS From: akbansal@hss.hns.com To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Message-ID: <65256C92.0036203E.00@sandesh.hss.hns.com> Date: Tue, 17 Dec 2002 15:18:51 +0530 Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Kishore I am not saying that it is not an implementation issue. Its just there is an exception to the statement from 2960 : 1.3.3 User Data Fragmentation On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. The Diameter implementation will have to block till it has received the entire message if it spans multiple SCTP packets. -Ankit Ext-Venkata.Ghadiyaram@nokia.com on 12/17/2002 03:15:28 PM To: Ankit Bansal/HSS@HSS, aaa-wg@merit.edu cc: Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Hi Ankit, Even if Diameter messages arrive in multiple packets, how does it require any change to the Diameter specicication. Is this not an implementation issue? - Kishore -----Original Message----- From: ext akbansal@hss.hns.com [mailto:akbansal@hss.hns.com] Sent: 17. December 2002 10:59 To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Hi section 6.9 of 2960 says "Note: If the data receiver runs out of buffer space while still waiting for more fragments to complete the re-assembly of the message, it should dispatch part of its inbound message through a partial delivery API (see Section 10), freeing some of its receive buffer space so that the rest of the message may be received." section 3.1.4 of draft-ietf-tsvwg-sctpsocket-05.txt says: "If the SCTP stack is running low on buffers, it may partially deliver a message. In this case, MSG_EOR will not be set, and more calls to recvmsg() will be necessary to completely consume the message. Only one message at a time can be partially delivered." Doesn't it mean that one Diameter message may arrive in multiple SCTP packets to the Diameter implementation? Regards -Ankit john.loughney@nokia.com on 12/17/2002 02:13:06 PM To: Adrian.Constantin@nokia.com, aaa-wg@merit.edu cc: (bcc: Ankit Bansal/HSS) Subject: RE: [AAA-WG]: Diameter messages vs. SCTP packets Adrian, One further comment. SCTP provides fragmentation & re-assembly services for the upper layer protocol. From 2960: 1.3.3 User Data Fragmentation When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. So I don't think we need to worry about your concerns. More interesting SCTP reading can be found here (disclaimer - I am a co-auther of 3257). Stream Control Transmission Protocol Applicability Statement (RFC 3257) http://www.ietf.org/rfc/rfc3257.txt br, John > -----Original Message----- > From: ext [mailto:Adrian.Constantin@nokia.com] > Sent: 16 December, 2002 19:17 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter messages vs. SCTP packets > > > Hi, > > The base specification and the transport profile do not > mandate anything about how the Diameter messages are > encapsulated in the SCTP packets. This means that a Diameter > implementation must be prepared to receive all possible > combinations, e.g. one Diameter message sent in multiple SCTP > packets or 1.5 Diameter messages in one SCTP packets. > > The receiver would be greatly simplified if one of the > specifications requires that a SCTP packet contains a > non-fractional number of Diameter messages. > > Regards, > > Adrian > From owner-aaa-wg@merit.edu Wed Dec 18 11:45:04 2002 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 LAA12433 for ; Wed, 18 Dec 2002 11:45:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CAC09912B1; Wed, 18 Dec 2002 11:47:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E311912B2; Wed, 18 Dec 2002 11:47:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE222912B1 for ; Wed, 18 Dec 2002 11:47:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 060645DE2D; Wed, 18 Dec 2002 11:47:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 7105F5DD9A for ; Wed, 18 Dec 2002 11:47:00 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBIGkF022411 for ; Wed, 18 Dec 2002 18:46:15 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Dec 2002 18:46:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Dec 2002 18:46:58 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Dec 2002 18:46:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Query on AAA Transport profile Date: Wed, 18 Dec 2002 18:46:57 +0200 Message-ID: <9E3407CE45911B4097632389B77B2023017DFABD@esebe014.ntc.nokia.com> Thread-Topic: Query on AAA Transport profile Thread-Index: AcKmtSRirKugag3HEdetjgAADnz2vQ== From: To: X-OriginalArrivalTime: 18 Dec 2002 16:46:57.0576 (UTC) FILETIME=[14113A80:01C2A6B5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12433 Hi, I have one query on AAA Transport Profile draft. In Appendix A where the algorithm is detailed, says 1. The action to be performed when the number of DWAs received in REPOEN state, is just incrementing NumDWA. Should not the action also include SetWatchDog()? 2. The action performed when the connection is down on OK state is closing the connection and setting the watch dog timer. Should not the action also include failover()? Present text : REOPEN Receive DWA & NumDWA < 2 NumDWA++ REOPEN OKAY Connection down Close Connection SetWatchdog() DOWN My understanding : REOPEN Receive DWA & NumDWA++ NumDWA < 2 SetWatchdog() REOPEN OKAY Connection down Close Connection failover() SetWatchdog() DOWN Thanks in advance, Kishore From owner-aaa-wg@merit.edu Thu Dec 19 19:28:46 2002 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 TAA02026 for ; Thu, 19 Dec 2002 19:28:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5BDB9125B; Thu, 19 Dec 2002 19:31:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A1649129C; Thu, 19 Dec 2002 19:31:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2A179125B for ; Thu, 19 Dec 2002 19:31:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD2BB5DDF7; Thu, 19 Dec 2002 19:31:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 576E35DDD7 for ; Thu, 19 Dec 2002 19:31:24 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBJNNra28584; Thu, 19 Dec 2002 15:23:53 -0800 Date: Thu, 19 Dec 2002 15:23:53 -0800 (PST) From: Bernard Aboba To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Query on AAA Transport profile In-Reply-To: <9E3407CE45911B4097632389B77B2023017DFABD@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > 1. The action to be performed when the number of DWAs received in REPOEN state, > is just incrementing NumDWA. Should not the action also include > SetWatchDog()? No. The watchdog timer is set after it expires, not after receipt of the NumDWA. Recall the other two states: REOPEN SendWatchdog & !Pending SetWatchdog() REOPEN REOPEN SendWatchdog & Pending SetWatchdog() REOPEN > 2. The action performed when the connection is down on OK state is >closing the connection and setting the watch dog timer. Should not the >action also include failover()? I don't think so. Failover() is called earlier, in the SUSPECT state. So there's no need to call it again. From owner-aaa-wg@merit.edu Fri Dec 20 03:04:55 2002 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 DAA18993 for ; Fri, 20 Dec 2002 03:04:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 510879120C; Fri, 20 Dec 2002 03:07:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 475139123B; Fri, 20 Dec 2002 03:07:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB1E79120C for ; Fri, 20 Dec 2002 03:03:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 646EA5DE3E; Fri, 20 Dec 2002 03:03:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 754855DD9A for ; Fri, 20 Dec 2002 03:03:05 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBK82I024240 for ; Fri, 20 Dec 2002 10:02:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 20 Dec 2002 10:03:04 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Dec 2002 10:03:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Query on AAA Transport profile Date: Fri, 20 Dec 2002 10:03:02 +0200 Message-ID: <9E3407CE45911B4097632389B77B202301870274@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Query on AAA Transport profile Thread-Index: AcKnvyBmneULksTOTLWUFSDIGTd/FgAPKw5A From: To: Cc: X-OriginalArrivalTime: 20 Dec 2002 08:03:03.0071 (UTC) FILETIME=[3877EAF0:01C2A7FE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18993 Hi Bernard, > 1. The action to be performed when the number of DWAs received in REPOEN state, > is just incrementing NumDWA. Should not the action also include > SetWatchDog()? No. The watchdog timer is set after it expires, not after receipt of the NumDWA. [Kishore]Thanks for the clarification. Recall the other two states: REOPEN SendWatchdog & !Pending SetWatchdog() REOPEN REOPEN SendWatchdog & Pending SetWatchdog() REOPEN [Kishore]Now I see some redundancy here. Why is it not just REOPEN SendWatchdog SetWatchdog() REOPEN > 2. The action performed when the connection is down on OK state is >closing the connection and setting the watch dog timer. Should not the >action also include failover()? I don't think so. Failover() is called earlier, in the SUSPECT state. So there's no need to call it again. [Kishore]I was referring to the case when the connection goes down in OK state. OKAY Connection down Close Connection SetWatchdog() DOWN It does not enter the SUSPECT state at all. Example is the case when a connnection is abruptly closed by the peer due to some unknown error. Regards, Kishore From owner-aaa-wg@merit.edu Fri Dec 20 09:31:35 2002 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 JAA28134 for ; Fri, 20 Dec 2002 09:31:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5EBCA9125D; Fri, 20 Dec 2002 09:34:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E3569129C; Fri, 20 Dec 2002 09:34:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39C119125D for ; Fri, 20 Dec 2002 09:34:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 454035DFAE; Fri, 20 Dec 2002 09:34:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8730C5DEF3 for ; Fri, 20 Dec 2002 09:34:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBKDQmS10510; Fri, 20 Dec 2002 05:26:48 -0800 Date: Fri, 20 Dec 2002 05:26:48 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Re: FW: I-D ACTION:draft-ietf-aaa-diameter-16.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Found a few gremlins... Section 2.4 Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff Section 11.3 Diameter Base Accounting 0 NASREQ 1 [NASREQ] Mobile-IP 4 [DIAMMIP] Relay 0xffffffff This seems to contradict section 2.4. Section 2.10 By authorizing a request, the home Diameter server is implicitly indicating its willingness to engage in the business transaction as specified by the contractual relationship between the server and the previous hop? A DIAMETER_AUTHORIZATION_REJECTED error message (see Section 7.1.5) is sent if the route traversed by the request is unacceptable. Remove the "?" From owner-aaa-wg@merit.edu Fri Dec 20 12:04:10 2002 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 MAA02150 for ; Fri, 20 Dec 2002 12:04:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 45534912D9; Fri, 20 Dec 2002 12:07:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10A6E912DA; Fri, 20 Dec 2002 12:06:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2151A912D9 for ; Fri, 20 Dec 2002 12:06:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 086A05DDF0; Fri, 20 Dec 2002 12:06:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 734515DDEE for ; Fri, 20 Dec 2002 12:06:58 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBKFxLU18857; Fri, 20 Dec 2002 07:59:21 -0800 Date: Fri, 20 Dec 2002 07:59:21 -0800 (PST) From: Bernard Aboba To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Query on AAA Transport profile In-Reply-To: <9E3407CE45911B4097632389B77B202301870274@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > No. The watchdog timer is set after it expires, not after receipt of the > NumDWA. > [Kishore]Thanks for the clarification. The goal is to be conservative about re-opening a connection once it has gone down, requiring two timer expirations, not just two DWAs. > [Kishore]Now I see some redundancy here. Why is it not just > REOPEN SendWatchdog SetWatchdog() REOPEN Yes. In fact, in looking at the code and statemachine, it's not clear why this entry is there at all. It can be consolidated into the other entries. > It does not enter the SUSPECT state at all. Example is the case when a connnection > is abruptly closed by the peer due to some unknown error. Yes. This is correct. In going over the sample code and state machine, I've also noticed a number of inconsistencies between them. A cleaned up version of the code and state machine, are available here: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-10.txt From owner-aaa-wg@merit.edu Fri Dec 20 14:02:38 2002 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 OAA06544 for ; Fri, 20 Dec 2002 14:02:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31D5C912E4; Fri, 20 Dec 2002 14:05:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB04F912E5; Fri, 20 Dec 2002 14:05:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D959912E4 for ; Fri, 20 Dec 2002 14:05:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF6365DF1D; Fri, 20 Dec 2002 14:05:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 20AD05DEDF for ; Fri, 20 Dec 2002 14:05:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBKHvrs25494 for ; Fri, 20 Dec 2002 09:57:53 -0800 Date: Fri, 20 Dec 2002 09:57:53 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Resolution of Issue #394 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 394 relates to the Transport state machine. The Transport document has gone through IETF last call and IESG review, and has been appoved as a Proposed Standard. Therefore changes are somewhat painful to make at this time. However, Issue 394 seems substantive to be worth resolving. The proposed fix is as to revise the code and state machine as follows: SetWatchdog() { /* SetWatchdog() is called whenever it is necessary to reset the watchdog timer Tw. The value of the watchdog timer is calculated based on the default initial value TWINIT and a jitter ranging from -2 to 2 seconds. The default for TWINIT is 30 seconds, and MUST NOT be set lower than 6 seconds. */ Tw=TWINIT -2.0 + 4.0 * random() ; SetTimer(Tw) ; return ; } /* OnReceive() is called whenever a message is received from the peer. This message MAY be a request or an answer, and can include DWR and DWA messages. Pending is assumed to be a global variable. */ OnReceive(pcb, msgType) { if (msgType == DWA) { Pending = FALSE; } switch (pcb->Status){ case OKAY: SetWatchdog(); break; case SUSPECT: pcb->Status = OKAY; Failback(pcb); SetWatchdog(); break; case REOPEN: if (msgType == DWA) { NumDWA++; if (NumDWA == 3) { pcb->status = OKAY; Failback(); } } else { Throwaway(received packet); } break; case INITIAL: case DOWN: Throwaway(received packet); break; default: Error("Shouldn't be here!"); break; } } /* OnTimerElapsed() is called whenever Tw reaches zero (0). */ OnTimerElapsed(pcb) { switch (pcb->status){ case OKAY: if (!Pending) { SendWatchdog(pbc); SetWatchdog(); Pending = TRUE; break; } pcb->status = SUSPECT; FailOver(pcb); SetWatchdog(); break ; case SUSPECT: pcb->status = DOWN; CloseConnection(pcb); SetWatchdog(); break; case INITIAL: case DOWN: AttemptOpen(pcb); SetWatchdog(); break; case REOPEN: if (!Pending) { SendWatchdog(pbc); SetWatchdog(); Pending = TRUE; break; } if (NumDWA < 0) { pcb->status = DOWN; CloseConnection(pcb); } else { NumDWA = -1; } SetWatchdog(); break; default: error("Shouldn't be here!); break; } } /* OnConnectionUp() is called whenever a connection comes up */ OnConnectionUp(pcb) { switch (pcb->status){ case INITIAL: pcb->status = OKAY; SetWatchdog(); break; case DOWN: pcb->status = REOPEN; NumDWA = 0; SendWatchdog(pcb); SetWatchdog(); Pending = TRUE; break; default: error("Shouldn't be here!); break; } } /* OnConnectionDown() is called whenever a connection goes down */ OnConnectionDown(pcb) { pcb->status = DOWN; CloseConnection(); switch (pcb->status){ case OKAY: Failover(pcb); SetWatchdog(); break; case INITIAL: case SUSPECT: case REOPEN: SetWatchdog(); break; case DOWN: break; default: error("Shouldn't be here!); break; } } /* Here is the state machine STATE Event Actions New State ===== ------ ------- ---------- OKAY Receive DWA Pending = FALSE SetWatchdog() OKAY OKAY Receive non-DWA SetWatchdog() OKAY SUSPECT Receive DWA Pending = FALSE SetWatchdog() Failback() OKAY REOPEN Receive DWA & Pending = FALSE NumDWA == 2 NumDWA++ Failback() OKAY REOPEN Receive DWA & Pending = FALSE NumDWA < 2 NumDWA++ REOPEN REOPEN Receive Non DWA Throwaway() REOPEN INITIAL Receive DWA Pending = FALSE Throwaway() INITIAL INITIAL Receive non-DWA Throwaway() INITIAL DOWN Receive DWA Pending = FALSE Throwaway() DOWN DOWN Receive non-DWA Throwaway() DOWN OKAY Timer expires & SendWatchdog() !Pending SetWatchdog() Pending = TRUE OKAY OKAY Timer expires & FailOver() Pending SetWatchdog() SUSPECT SUSPECT Timer expires CloseConnection() SetWatchdog() DOWN INITIAL Timer expires AttemptOpen() SetWatchdog() INITIAL DOWN Timer expires AttemptOpen() SetWatchdog() DOWN REOPEN Timer expires & SendWatchdog() !Pending SetWatchdog() Pending = TRUE REOPEN REOPEN Timer expires & CloseConnection() Pending & SetWatchdog NumDWA < 0 DOWN REOPEN Timer expires & NumDWA = -1 Pending & SetWatchdog() NumDWA >= 0 REOPEN INITIAL Connection up SetWatchDog() OKAY DOWN Connection up NumDWA = 0 SendWatchdog() SetWatchdog() Pending = TRUE REOPEN OKAY Connection down CloseConnection() Failover() SetWatchdog() DOWN SUSPECT Connection down CloseConnection() SetWatchdog() DOWN REOPEN Connection down CloseConnection() SetWatchdog() DOWN DOWN Connection down CloseConnection() DOWN INITIAL Connection down CloseConnection() SetWatchdog() DOWN */ From owner-aaa-wg@merit.edu Mon Dec 23 08:08:45 2002 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 IAA28990 for ; Mon, 23 Dec 2002 08:08:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1702E9122E; Mon, 23 Dec 2002 08:11:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6AF791230; Mon, 23 Dec 2002 08:11:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E727A9122E for ; Mon, 23 Dec 2002 08:11:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8F085DF4E; Mon, 23 Dec 2002 08:11:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5E6295DF4B for ; Mon, 23 Dec 2002 08:11:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBNC3ca19462 for ; Mon, 23 Dec 2002 04:03:38 -0800 Date: Mon, 23 Dec 2002 04:03:37 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: REMINDER: Only 6 more shopping days until NASREQ-10 last call ends! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a reminder that AAA WG Last Call is ongoing on draft-ietf-aaa-diameter-nasreq-10.txt, which is being considered for advancement as an IETF Proposed Standard. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt So far, we have had one comment on this draft (thanks, Jari!). The ability of AAA WG to take on new work items is in part constrained by our ability to finish old ones. So even if NASREQ is not your main interest, please put some time aside to read it and send in your comments during the upcoming Holidays. AAA WG last call on NASREQ-10 will run until December 28, 2002. Please send comments to the authors or aaa-wg@merit.edu, using the Issues submission template found at: http://www.drizzle.com/~aboba/AAA/issues.html In particular, it is requested that commenters not only identify problems in the draft, but send text to fix the identified issues. From owner-aaa-wg@merit.edu Tue Dec 24 04:26:25 2002 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 EAA04747 for ; Tue, 24 Dec 2002 04:26:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A82AF91240; Tue, 24 Dec 2002 04:29:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 679C69125F; Tue, 24 Dec 2002 04:29:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1AA2791240 for ; Tue, 24 Dec 2002 04:29:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC5E15DF29; Tue, 24 Dec 2002 04:29:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 2EC4C5DE6D for ; Tue, 24 Dec 2002 04:29:13 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBO9SQ014827 for ; Tue, 24 Dec 2002 11:28:26 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Dec 2002 11:26:42 +0200 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Dec 2002 11:26:41 +0200 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Dec 2002 17:26:35 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: A question in NASREQ section 2.1 Date: Tue, 24 Dec 2002 17:26:34 +0800 Message-ID: Thread-Topic: [AAA-WG]: REMINDER: Only 6 more shopping days until NASREQ-10 last call ends! Thread-Index: AcKqhPWAR1g4nPoUSpaAKKsEvmPmTwAp1sLQ From: To: , X-OriginalArrivalTime: 24 Dec 2002 09:26:35.0476 (UTC) FILETIME=[8DBF3940:01C2AB2E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04747 In NASREQ section 2.1, "The failure to start a session SHOULD cause an Accounting EVENT_RECORD message." But regards to the following scenario, where will the Accounting EVENT_RECORD message be addressed to? +--------+ +-------+ +-------------+ | NAS |--------| Relay |--------| Auth Server | +--------+ +---+---+ +-------------+ | | +------+------+ | Acct Server | +-------------+ Best regards, roger From owner-aaa-wg@merit.edu Tue Dec 24 09:22:11 2002 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 JAA07868 for ; Tue, 24 Dec 2002 09:22:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64D2D9122A; Tue, 24 Dec 2002 09:24:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38C9B91235; Tue, 24 Dec 2002 09:24:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A46D9122A for ; Tue, 24 Dec 2002 09:24:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 01C175DDFF; Tue, 24 Dec 2002 09:24:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h002.c000.snv.cp.net [209.228.32.66]) by segue.merit.edu (Postfix) with SMTP id 740D15DDAF for ; Tue, 24 Dec 2002 09:24:57 -0500 (EST) Received: (cpmta 18940 invoked from network); 24 Dec 2002 06:24:56 -0800 Received: from 69.3.41.106 (HELO DMITTON-IBMTP.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 24 Dec 2002 06:24:56 -0800 X-Sent: 24 Dec 2002 14:24:56 GMT Message-Id: <5.2.0.9.2.20021224092304.0426ae90@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 24 Dec 2002 09:24:29 -0500 To: , , From: David Mitton Subject: Re: [AAA-WG]: A question in NASREQ section 2.1 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 12/24/2002 05:26 PM +0800, qing.roger.liu@nokia.com wrote: >In NASREQ section 2.1, >"The failure to start a session SHOULD cause an Accounting EVENT_RECORD >message." > >But regards to the following scenario, where will the Accounting >EVENT_RECORD message be addressed to? > > +--------+ +-------+ +-------------+ > | NAS |--------| Relay |--------| Auth Server | > +--------+ +---+---+ +-------------+ > | > | > +------+------+ > | Acct Server | > +-------------+ > >Best regards, >roger Where would a successful Accounting message go? What criteria is the Relay using to split the streams? How would the source know that? Who configured this? Dave. From owner-aaa-wg@merit.edu Wed Dec 25 18:10:20 2002 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 SAA22059 for ; Wed, 25 Dec 2002 18:10:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3142F91239; Wed, 25 Dec 2002 18:13:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB16391244; Wed, 25 Dec 2002 18:13:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E90E491239 for ; Wed, 25 Dec 2002 18:13:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB9D45DE4B; Wed, 25 Dec 2002 18:13:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1FDB75DE00 for ; Wed, 25 Dec 2002 18:13:08 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBPM58Y16826 for ; Wed, 25 Dec 2002 14:05:08 -0800 Date: Wed, 25 Dec 2002 14:05:08 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Transport-10 review (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=------------060705010708090707020704 Content-ID: Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------060705010708090707020704 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Thank you. It seems to make sense that *any* message in SUSPECT state will cause failback. ---------- Forwarded message ---------- Date: Thu, 26 Dec 2002 01:00:07 +0200 From: Jari Arkko To: Bernard Aboba Cc: Jari Arkko Subject: Transport-10 review Ok, here's some preliminary results. The claim I set out to prove was "The code in transport-10 is equivalent to the state machine in transport-10". The answer is no. Well, its almost equivalent modulo some editorial nits (see attachment) and one real difference. You should fix the editorials, and we can discuss the real difference: the code assumes that if you get *any* message in the SUSPECT state you will immediately failback and go to OKAY. I'm not quite sure what's right here. Perhaps this depends on the assumptions on what the transport layer is doing. I might be easily convinced that any message is good enough; if the peer is responding on either TCP or SCTP then there must be some bidirectional connectivity. Note that on the application layer you could be just getting DWR which doesn't prove that the peer app has heard you. But maybe this is enough. Then there's a few further questions which you might want some answers. I have marked the answers below in case I have them. Getting the rest would mean more work. - Does the state machine make sense? It does make sense to me. I went through all of it. That doesn't prove anything, of course. - Can the state machine deadlock? Hmm.... partial answer below regarding forgetting to set the timer. Otherwise, I don't know. - Can the state machine livelock? I think so, you could be stuck forever in REOPEN if the sequence of received/missed DWAs is right. I believe this is a feature, however, not a bug. - Is the value of NumDWA in bounds -1..3? Yes. Thank god the assignment is "NumDWA = -1", not "NumDWA--"... - Do we sometimes forget to set the timer, and be doomed for waiting it forever? I don't think so. All "timer expired" events lead to SetWatchdog call in all cases. Nice. Jari --------------060705010708090707020704 Content-Type: TEXT/PLAIN; NAME="state-machine-observations.txt" Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="state-machine-observations.txt" - It doesn't seem possible to get ConnectionDown event in the INITIAL state. Nice to have the state machine be complete, but this will never happen... - In the line "INITIAL Connection up SetWatchDog() OKAY" you should change s/WatchDog/Watchdog/ - In the line " Pending & SetWatchdog" you should change s/Watchdog/Watchdog()/ - In the entry "SUSPECT Receive DWA Pending = FALSE SetWatchdog() Failback() OKAY" you should swap the order of the two last actions. - In the line "REOPEN Receive Non DWA Throwaway() REOPEN" you should change s/Non DWA/non-DWA/ --------------060705010708090707020704 Content-Type: TEXT/PLAIN; NAME="state-machine-code.txt" Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="state-machine-code.txt" STATE Event Actions New State ===== ------ ------- ---------- DOWN Connection down CloseConnection() DOWN DOWN Connection up NumDWA = 0; SendWatchdog(); SetWatchdog(); Pending = TRUE REOPEN DOWN Receive DWA Pending = FALSE; Throwaway() DOWN DOWN Receive non-DWA Throwaway() DOWN DOWN Timer expires AttemptOpen(); SetWatchdog() DOWN INITIAL Connection down CloseConnection(); SetWatchdog() DOWN INITIAL Connection up SetWatchdog() OKAY INITIAL Receive DWA Pending = FALSE; Throwaway() INITIAL INITIAL Receive non-DWA Throwaway() INITIAL INITIAL Timer expires AttemptOpen(); SetWatchdog() INITIAL OKAY Connection down CloseConnection(); Failover(); SetWatchdog() DOWN OKAY Receive DWA Pending = FALSE; SetWatchdog() OKAY OKAY Receive non-DWA SetWatchdog() OKAY OKAY Timer expires & !Pending SendWatchdog(); SetWatchdog(); Pending = TRUE OKAY OKAY Timer expires & Pending FailOver(); SetWatchdog() SUSPECT REOPEN Connection down CloseConnection(); SetWatchdog() DOWN REOPEN Receive DWA & NumDWA < 2 Pending = FALSE; NumDWA++ REOPEN REOPEN Receive DWA & NumDWA == 2 Pending = FALSE; NumDWA++; Failback() OKAY REOPEN Receive non-DWA Throwaway() REOPEN REOPEN Timer expires & !Pending SendWatchdog(); SetWatchdog(); Pending = TRUE REOPEN REOPEN Timer expires & Pending & NumDWA < 0 CloseConnection(); SetWatchdog() DOWN REOPEN Timer expires & Pending & NumDWA >= 0 NumDWA = -1; SetWatchdog() REOPEN SUSPECT Connection down CloseConnection(); SetWatchdog() DOWN SUSPECT Receive DWA Pending = FALSE; Failback(); SetWatchdog() OKAY SUSPECT Receive non-DWA Failback(); SetWatchdog() OKAY SUSPECT Timer expires CloseConnection(); SetWatchdog() DOWN --------------060705010708090707020704 Content-Type: TEXT/PLAIN; NAME="state-machine-code-base.txt" Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="state-machine-code-base.txt" /* OnReceive() is called whenever a message is received from the peer. This message MAY be a request or an answer, and can include DWR and DWA messages. Pending is assumed to be a global variable. */ OnReceive(pcb, msgType) { if (msgType == DWA) { Pending = FALSE; } switch (pcb->Status){ case OKAY: SetWatchdog(); break; case SUSPECT: pcb->Status = OKAY; Failback(pcb); SetWatchdog(); break; case REOPEN: if (msgType == DWA) { NumDWA++; if (NumDWA == 3) { pcb->status = OKAY; Failback(); } } else { Throwaway(received packet); } break; case INITIAL: case DOWN: Throwaway(received packet); break; default: Error("Shouldn't be here!"); break; } } /* OnTimerElapsed() is called whenever Tw reaches zero (0). */ OnTimerElapsed(pcb) { switch (pcb->status){ case OKAY: if (!Pending) { SendWatchdog(pbc); SetWatchdog(); Pending = TRUE; break; } pcb->status = SUSPECT; FailOver(pcb); SetWatchdog(); break ; case SUSPECT: pcb->status = DOWN; CloseConnection(pcb); SetWatchdog(); break; case INITIAL: case DOWN: AttemptOpen(pcb); SetWatchdog(); break; case REOPEN: if (!Pending) { SendWatchdog(pbc); SetWatchdog(); Pending = TRUE; break; } if (NumDWA < 0) { pcb->status = DOWN; CloseConnection(pcb); } else { NumDWA = -1; } SetWatchdog(); break; default: error("Shouldn't be here!); break; } } /* OnConnectionUp() is called whenever a connection comes up */ OnConnectionUp(pcb) { switch (pcb->status){ case INITIAL: pcb->status = OKAY; SetWatchdog(); break; case DOWN: pcb->status = REOPEN; NumDWA = 0; SendWatchdog(pcb); SetWatchdog(); Pending = TRUE; break; default: error("Shouldn't be here!); break; } } /* OnConnectionDown() is called whenever a connection goes down */ OnConnectionDown(pcb) { pcb->status = DOWN; CloseConnection(); switch (pcb->status){ case OKAY: Failover(pcb); SetWatchdog(); break; case INITIAL: case SUSPECT: case REOPEN: SetWatchdog(); break; case DOWN: break; default: error("Shouldn't be here!); break; } } --------------060705010708090707020704 Content-Type: TEXT/PLAIN; NAME="state-machine-orig.txt" Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="state-machine-orig.txt" STATE Event Actions New State ===== ------ ------- ---------- DOWN Connection down CloseConnection() DOWN DOWN Connection up NumDWA = 0; SendWatchdog(); SetWatchdog(); Pending = TRUE REOPEN DOWN Receive DWA Pending = FALSE; Throwaway() DOWN DOWN Receive non-DWA Throwaway() DOWN DOWN Timer expires AttemptOpen(); SetWatchdog() DOWN INITIAL Connection down CloseConnection(); SetWatchdog() DOWN INITIAL Connection up SetWatchdog() OKAY INITIAL Receive DWA Pending = FALSE; Throwaway() INITIAL INITIAL Receive non-DWA Throwaway() INITIAL INITIAL Timer expires AttemptOpen(); SetWatchdog() INITIAL OKAY Connection down CloseConnection(); Failover(); SetWatchdog() DOWN OKAY Receive DWA Pending = FALSE; SetWatchdog() OKAY OKAY Receive non-DWA SetWatchdog() OKAY OKAY Timer expires & !Pending SendWatchdog(); SetWatchdog(); Pending = TRUE OKAY OKAY Timer expires & Pending FailOver(); SetWatchdog() SUSPECT REOPEN Connection down CloseConnection(); SetWatchdog() DOWN REOPEN Receive DWA & NumDWA < 2 Pending = FALSE; NumDWA++ REOPEN REOPEN Receive DWA & NumDWA == 2 Pending = FALSE; NumDWA++; Failback() OKAY REOPEN Receive non-DWA Throwaway() REOPEN REOPEN Timer expires & !Pending SendWatchdog(); SetWatchdog(); Pending = TRUE REOPEN REOPEN Timer expires & Pending & NumDWA < 0 CloseConnection(); SetWatchdog() DOWN REOPEN Timer expires & Pending & NumDWA >= 0 NumDWA = -1; SetWatchdog() REOPEN SUSPECT Connection down CloseConnection(); SetWatchdog() DOWN SUSPECT Receive DWA Pending = FALSE; Failback(); SetWatchdog() OKAY SUSPECT Timer expires CloseConnection(); SetWatchdog() DOWN --------------060705010708090707020704-- From owner-aaa-wg@merit.edu Sat Dec 28 15:51:56 2002 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 PAA08833 for ; Sat, 28 Dec 2002 15:51:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4EA5A91224; Sat, 28 Dec 2002 15:54:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 061F391248; Sat, 28 Dec 2002 15:54:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB92A91224 for ; Sat, 28 Dec 2002 15:54:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id B13E95DFC3; Sat, 28 Dec 2002 15:54:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 3A89E5DDB3 for ; Sat, 28 Dec 2002 15:54:48 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gBSKs3C04180; Sat, 28 Dec 2002 12:54:04 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gBSKsEm22313; Sat, 28 Dec 2002 14:54:15 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 28 Dec 2002 14:54:01 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240759D05B@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: aaa-wg@merit.edu Cc: aboba@internaut.com, david@mitton.com Subject: [AAA-WG]: NASREQ-10 comments Date: Sat, 28 Dec 2002 14:53:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2AEB3.3D146140" Sender: owner-aaa-wg@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_01C2AEB3.3D146140 Content-Type: text/plain Hello, Here is a list of comments on nasreq-10 draft. The draft seems to be quite stable. Did not find any major issue. Regards, Kuntal ------------------------------------------------------------------------ Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: E Priority: 1 Section: 4.1.3 Rationale/Explanation of issue: ...This AVP SHOULD be present if the NAS uses the same NAS-Port number ranges for different services types concurrently. Proposal: ...This AVP SHOULD be present if the NAS uses the same NAS-Port number ranges for different service types concurrently. ---------------------------------------------------------------- Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: T Priority: 1 Section: 4.2.6 Rationale/Explanation of issue: CHAP with MD5 5 The CHAP response is computed using the procedure described in [PPPCHAP]. The CHAP-Response AVP MUST be present in the CHAP- Auth AVP. Comment: We should not talk about CHAP-Response AVP in the CHAP-Algorithm AVP section. Also according to the ABNF grammar, the CHAP-Response AVP is not mandatory in CHAP-Auth AVP. Proposal: Delete the paragraph below CHAP with MD5 5. ----------------------------------------------------------------- Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: T Priority: 2 Section: 4.4 Rationale/Explanation of issue: Tunneling AVP is of type Grouped but MAY NOT be encrypted. Whereas CHAP-Auth AVP MAY be encrypted, but it is of type Grouped as well. In the entire spec Tunneling AVP is the only one that has "N" in MAY Encr column. Is this an error or is there a reason for it? Since almost all of the AVPs have MAY Encr = Y this column can be replaced by a global declaration ( e.g. may encrypt all AVPs). ------------------------------------------------------------------- Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: T Priority: 1 Section: 5.8 Rationale/Explanation of issue: Acct-Multi- Accounting- Acct- Session-Id Session-Id Record-Type Link-Count -------------------------------------------------------- "...10" "...10" START_RECORD 1 "...10" "...11" START_RECORD 2 "...10" "...11" STOP_RECORD 2 "...10" "...12" START_RECORD 3 "...10" "...13" START_RECORD 4 "...10" "...12" STOP_RECORD 4 "...10" "...13" STOP_RECORD 4 "...10" "...10" STOP_RECORD 4 At the fourth step, the Acct-Link-Count should be 2, because at the third step the link with session-Id ...11 was closed, thus leaving only session-Id ...10 open. ---------------------------------------------------------------- Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: T Priority: 1 Section: 6.1.1 Rationale/Explanation of issue: - If a Proxy-Info AVP is present, extract the encoded information, otherwise retrieve the information from the local state table. - If a Proxy-Info AVP was present in the request, the same AVP MUST be added to the response. The Proxy-Info AVP is not supported in RADIUS. Should it be Proxy-State AVP instead? ----------------------------------------------------------------- Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: E Priority: 1 Section: 6.2 Rationale/Explanation of issue: The AVPs defined in this section SHOULD only used for backwards compatibility when a Diameter/RADIUS translation function is invoked, and are not typically originated by Diameter systems. Proposal: The AVPs defined in this section SHOULD only be used for backward compatibility when a Diameter/RADIUS translation function is invoked, and are not typically originated by Diameter systems during normal operation. ---------------------------------------------------------------- Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: E/T Priority: 1 Section: 7.2.1 and 7.2.2 Rationale/Explanation of issue: The AVPs that are MUST not be present in a command Request/Answer are still shown in the table. Proposal: Section 7.2.1 State AVP MUST not be present in both ACR and ACA. There is no need to show it in the table. Delete this entry. Section 7.2.2: Same as above: delete Accounting-Input-Packets, Accounting-Output-Packets, NAS-Filter-Rule, State entries from the AVP table for these types of accounting messages. ----------------------------------------------------------------- Description of issue Submitter name: Kuntal Chowdhury Submitter email address: chowdury@nortelnetworks.com Date first submitted: 12/28/02 Reference: Document: nasreq Comment type: E Priority: 1 Section: 10 Rationale/Explanation of issue: Update reference for CDMA2000 with the latest release of the standard. [CDMA2000] 3GPP2 "P.S0001-A v3.0", Wireless IP Network Standard, July 2001. http://www.3gpp2.com/Public_html/specs/P.S0001-A_v3.0.pdf Proposal: [CDMA2000] 3GPP2 "P.S0001-B", Wireless IP Network Standard, October 2002. http://www.3gpp2.com/Public_html/specs/P.S0001-B_v1.0.pdf ------_=_NextPart_001_01C2AEB3.3D146140 Content-Type: text/html Content-Transfer-Encoding: quoted-printable NASREQ-10 comments

Hello,
Here is a list of comments on nasreq-10 draft. The = draft seems to be quite stable. Did not find any major issue.

Regards,
Kuntal

---------------------------------------------------------------= ---------
Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: E
Priority: 1
Section: 4.1.3
Rationale/Explanation of issue:
...This AVP SHOULD be present if the NAS uses the = same NAS-Port
   number ranges for different services = types concurrently.
Proposal:

...This AVP SHOULD be present if the NAS uses the = same NAS-Port
   number ranges for different service = types concurrently.
---------------------------------------------------------------= -

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: T
Priority: 1
Section: 4.2.6
Rationale/Explanation of issue:

      CHAP with = MD5       5
         The = CHAP response is computed using the procedure described in
         = [PPPCHAP].  The CHAP-Response AVP MUST be present in the = CHAP-
         = Auth AVP.

Comment: We should not talk about CHAP-Response AVP = in the CHAP-Algorithm
AVP section. Also according to the ABNF grammar, the = CHAP-Response AVP is
not mandatory in CHAP-Auth AVP.

Proposal: Delete the paragraph below CHAP with = MD5      5.
---------------------------------------------------------------= --

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: T
Priority: 2
Section: 4.4
Rationale/Explanation of issue:
Tunneling AVP is of type Grouped but MAY NOT be = encrypted. Whereas CHAP-Auth
AVP MAY be encrypted, but it is of type Grouped as = well. In the entire spec
Tunneling AVP is the only one that has "N" = in MAY Encr column. Is this an error
or is there a reason for it? Since almost all of the = AVPs have MAY Encr =3D Y
this column can be replaced by a global declaration = ( e.g. may encrypt all AVPs).
---------------------------------------------------------------= ----


Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: T
Priority: 1
Section: 5.8
Rationale/Explanation of issue:

       = Acct-Multi-          &= nbsp;        = Accounting-     Acct-
      = Session-Id     Session-Id     = Record-Type     Link-Count
      = --------------------------------------------------------
        = "...10"        = "...10"      = START_RECORD        1
        = "...10"        = "...11"      = START_RECORD        2
        = "...10"        = "...11"      = STOP_RECORD         2
        = "...10"        = "...12"      = START_RECORD        3
        = "...10"        = "...13"      = START_RECORD        4
        = "...10"        = "...12"      = STOP_RECORD         4
        = "...10"        = "...13"      = STOP_RECORD         4
        = "...10"        = "...10"      = STOP_RECORD         4

At the fourth step, the Acct-Link-Count should be 2, = because at the third
step the link with session-Id ...11 was closed, thus = leaving only session-Id
...10 open.
---------------------------------------------------------------= -

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: T
Priority: 1
Section: 6.1.1
Rationale/Explanation of issue:

      - If a Proxy-Info AVP = is present, extract the encoded information,
        otherwise = retrieve the information from the local state table.

      - If a Proxy-Info AVP = was present in the request, the same AVP
        MUST be = added to the response.
     
The Proxy-Info AVP is not supported in RADIUS. = Should it be Proxy-State AVP
instead?
---------------------------------------------------------------= --


Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: E
Priority: 1
Section: 6.2
Rationale/Explanation of issue:

   The AVPs defined in this section SHOULD = only used for backwards
   compatibility when a Diameter/RADIUS = translation function is invoked,
   and are not typically originated by = Diameter systems.

Proposal:
   The AVPs defined in this section SHOULD = only be used for backward
   compatibility when a Diameter/RADIUS = translation function is invoked,
   and are not typically originated by = Diameter systems during normal
   operation.
---------------------------------------------------------------= -

Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: E/T
Priority: 1
Section: 7.2.1 and 7.2.2
Rationale/Explanation of issue:
The AVPs that are MUST not be present in a command = Request/Answer are still
shown in the table.

Proposal:
Section 7.2.1
State AVP MUST not be present in both ACR and ACA. = There is no need to show
it in the table. Delete this entry.

Section 7.2.2:
Same as above: delete Accounting-Input-Packets, = Accounting-Output-Packets,
NAS-Filter-Rule, State entries from the AVP table = for these types of
accounting messages.
---------------------------------------------------------------= --


Description of issue
Submitter name: Kuntal Chowdhury
Submitter email address: = chowdury@nortelnetworks.com
Date first submitted: 12/28/02
Reference: 
Document:  nasreq
Comment type: E
Priority: 1
Section: 10
Rationale/Explanation of issue:

Update reference for CDMA2000 with the latest release = of the standard.

[CDMA2000]    3GPP2 "P.S0001-A = v3.0", Wireless IP Network Standard, July
          &nb= sp;   2001.
          &nb= sp;   http://www.3gpp2.com/Public_html/specs/P.S0001-A_v3.0.= pdf
Proposal:


[CDMA2000]    3GPP2 = "P.S0001-B", Wireless IP Network Standard, October
          &nb= sp;   2002.
          &nb= sp;   http://www.3gpp2.com/Public_html/specs/P.S0001-B_v1.0.= pdf

    

------_=_NextPart_001_01C2AEB3.3D146140-- From owner-aaa-wg@merit.edu Sat Dec 28 16:16:29 2002 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 QAA09055 for ; Sat, 28 Dec 2002 16:16:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 53E5191249; Sat, 28 Dec 2002 16:19:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 218439124A; Sat, 28 Dec 2002 16:19:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A0E791249 for ; Sat, 28 Dec 2002 16:19:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 236C55DFAD; Sat, 28 Dec 2002 16:19:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 996B45DF85 for ; Sat, 28 Dec 2002 16:19:22 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBSKB3s21154; Sat, 28 Dec 2002 12:11:03 -0800 Date: Sat, 28 Dec 2002 12:11:03 -0800 (PST) From: Bernard Aboba To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Transport-10 review In-Reply-To: <9E3407CE45911B4097632389B77B2023017DFAD2@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > It seems that the code and the state machine are still not in sync. > > Code onReceive(): > case DOWN: > Throwaway(received packet); > break; > > State machine : > DOWN Receive DWA Pending = FALSE > Throwaway() DOWN > DOWN Receive non-DWA Throwaway() DOWN > > Additionally, does it make sense to describe onReceive in DOWN state. Can one receive a message in DOWN state? > > - Kishore > Actually, this does appear consistent. The code reads: OnReceive(pcb, msgType) { if (msgType == DWA) { Pending = FALSE; } So the state machine input for the DOWN state needs to include Pending = FALSE as part of the actions when DWA is received, whereas this is not true when a non-DWA is received. From owner-aaa-wg@merit.edu Sat Dec 28 16:22:39 2002 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 QAA09101 for ; Sat, 28 Dec 2002 16:22:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 476359124A; Sat, 28 Dec 2002 16:25:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 191A79124B; Sat, 28 Dec 2002 16:25:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F9309124A for ; Sat, 28 Dec 2002 16:25:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1253C5DFC0; Sat, 28 Dec 2002 16:25:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8A0305DFAD for ; Sat, 28 Dec 2002 16:25:31 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBSKHDa21540; Sat, 28 Dec 2002 12:17:13 -0800 Date: Sat, 28 Dec 2002 12:17:12 -0800 (PST) From: Bernard Aboba To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Transport-10 review In-Reply-To: <9E3407CE45911B4097632389B77B2023017DFAD3@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sat, 28 Dec 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > Hi, > > Another inconsistency between section 3.4.1 and the pseodu code in the appendix. > > [2] When any AAA response is received, Tw is reset. This need not be a > response to a watchdog request. > > Should this not be > > [2] When any AAA message is received, Tw is reset. This need not be a > response to a watchdog request. > > Regards, > Kishore It is correct that any message will result in Tw being reset in the OKAY and SUSPECT states. I think that this is the right behavior (reflected in the code and state machine), but not in the 3.4.1 text. From owner-aaa-wg@merit.edu Sat Dec 28 16:26:18 2002 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 QAA09149 for ; Sat, 28 Dec 2002 16:26:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51D4A9124B; Sat, 28 Dec 2002 16:29:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 217C49124C; Sat, 28 Dec 2002 16:29:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29C779124B for ; Sat, 28 Dec 2002 16:29:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F22A5DFC7; Sat, 28 Dec 2002 16:29:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9A86E5DFC6 for ; Sat, 28 Dec 2002 16:29:10 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBSKKqw21746; Sat, 28 Dec 2002 12:20:52 -0800 Date: Sat, 28 Dec 2002 12:20:51 -0800 (PST) From: Bernard Aboba To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: RE: Transport-10 review In-Reply-To: <9E3407CE45911B4097632389B77B2023017DFAD4@esebe014.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Hi, > > INITIAL Connection down CloseConnection() > SetWatchdog() DOWN > > DOWN Connection down CloseConnection() DOWN > > What does the Connection down event mean when the conection does not exist >in INITIAL and DOWN states? > > Regards, > Kishore As Jari pointed out, a Connection down event can't occur in the INITIAL and DOWN states, so those entries can be deleted (and handled as error conditions). From owner-aaa-wg@merit.edu Sat Dec 28 17:49:24 2002 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 RAA10019 for ; Sat, 28 Dec 2002 17:49:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5342C9124D; Sat, 28 Dec 2002 17:52:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CE269124E; Sat, 28 Dec 2002 17:52:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 314AA9124D for ; Sat, 28 Dec 2002 17:52:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1896F5DF85; Sat, 28 Dec 2002 17:52:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 991235DF0F for ; Sat, 28 Dec 2002 17:52:17 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBSLi0S26241 for ; Sat, 28 Dec 2002 13:44:00 -0800 Date: Sat, 28 Dec 2002 13:44:00 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 396: BASE-16 NITS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 396: BASE-16 Nits Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: December 28, 2002 Reference: Document: BASE-16 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Section 2.4 Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff Section 11.3 Diameter Base Accounting 0 NASREQ 1 [NASREQ] Mobile-IP 4 [DIAMMIP] Relay 0xffffffff This seems to contradict section 2.4. Section 2.10 By authorizing a request, the home Diameter server is implicitly indicating its willingness to engage in the business transaction as specified by the contractual relationship between the server and the previous hop? A DIAMETER_AUTHORIZATION_REJECTED error message (see Section 7.1.5) is sent if the route traversed by the request is unacceptable. Remove the "?" From owner-aaa-wg@merit.edu Sun Dec 29 07:34:20 2002 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 HAA27418 for ; Sun, 29 Dec 2002 07:34:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5900591284; Sun, 29 Dec 2002 07:37:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D6E991285; Sun, 29 Dec 2002 07:37:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A03E91284 for ; Sun, 29 Dec 2002 07:37:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B6A15DDA0; Sun, 29 Dec 2002 07:37:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id C54B65DE71 for ; Sun, 29 Dec 2002 07:37:09 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C6E1D6A906; Sun, 29 Dec 2002 14:37:04 +0200 (EET) Message-ID: <3E0EDF90.9070500@kolumbus.fi> Date: Sun, 29 Dec 2002 13:42:08 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Ext-Venkata.Ghadiyaram@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Transport-10 review References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > On Sat, 28 Dec 2002 Ext-Venkata.Ghadiyaram@nokia.com wrote: > > >>Hi, >> >>Another inconsistency between section 3.4.1 and the pseodu code in the appendix. >> >>[2] When any AAA response is received, Tw is reset. This need not be a >> response to a watchdog request. >> >>Should this not be >> >>[2] When any AAA message is received, Tw is reset. This need not be a >> response to a watchdog request. >> >>Regards, >>Kishore > > > It is correct that any message will result in Tw being reset in the OKAY > and SUSPECT states. I think that this is the right behavior (reflected in > the code and state machine), but not in the 3.4.1 text. Yes. Change s/response/message/ in 3.4.1. Jari From owner-aaa-wg@merit.edu Sun Dec 29 07:34:44 2002 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 HAA27456 for ; Sun, 29 Dec 2002 07:34:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7FB5491287; Sun, 29 Dec 2002 07:37:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48CB291240; Sun, 29 Dec 2002 07:37:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 234AF91240 for ; Sun, 29 Dec 2002 07:37:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id F0D845DFDD; Sun, 29 Dec 2002 07:37:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B88AD5DDA0 for ; Sun, 29 Dec 2002 07:37:09 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D12B46A905; Sun, 29 Dec 2002 14:37:03 +0200 (EET) Message-ID: <3E0EDF89.4040807@kolumbus.fi> Date: Sun, 29 Dec 2002 13:42:01 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Ext-Venkata.Ghadiyaram@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: Transport-10 review References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes, Bernard is right that the sm & code are consistent in this case. It is still a good question whether it makes sense to talk about receptions in the DOWN state. Strictly speaking, your socket is going to be closed when you are in DOWN, so you can't receive anything... but we might leave the entries just to avoid too many changes at this stage. They don't hurt anyone, and given Bernard's if statement outside the switch, he'd have to make a not-so-easy change to the code in order to remove them. Jari Bernard Aboba wrote: >>It seems that the code and the state machine are still not in sync. >> >>Code onReceive(): >> case DOWN: >> Throwaway(received packet); >> break; >> >>State machine : >>DOWN Receive DWA Pending = FALSE >> Throwaway() DOWN >>DOWN Receive non-DWA Throwaway() DOWN >> >>Additionally, does it make sense to describe onReceive in DOWN state. Can one receive a message in DOWN state? >> >>- Kishore >> > > > Actually, this does appear consistent. The code reads: > > OnReceive(pcb, msgType) > { > if (msgType == DWA) { > Pending = FALSE; > } > > So the state machine input for the DOWN state needs to include Pending = > FALSE as part of the actions when DWA is received, whereas this is not > true when a non-DWA is received. > > From owner-aaa-wg@merit.edu Sun Dec 29 12:00:15 2002 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 MAA29974 for ; Sun, 29 Dec 2002 12:00:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1435F91235; Sun, 29 Dec 2002 12:03:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE09491236; Sun, 29 Dec 2002 12:03:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D82F391235 for ; Sun, 29 Dec 2002 12:03:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D77C5DE1C; Sun, 29 Dec 2002 12:03:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B04FB5DDA3 for ; Sun, 29 Dec 2002 12:03:01 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id gBTFsYf24547; Sun, 29 Dec 2002 07:54:35 -0800 Date: Sun, 29 Dec 2002 07:54:34 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: Ext-Venkata.Ghadiyaram@nokia.com, Subject: Re: [AAA-WG]: RE: Transport-10 review In-Reply-To: <3E0EDF89.4040807@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk We'll do a -12 revision to fix 3.4.1 and remove the Connection down events in the DOWN and INITIAL states. A strawman is available at: http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-12.txt On Sun, 29 Dec 2002, Jari Arkko wrote: > > Yes, Bernard is right that the sm & code are consistent in this case. > It is still a good question whether it makes sense to talk about > receptions in the DOWN state. Strictly speaking, your socket is > going to be closed when you are in DOWN, so you can't receive > anything... but we might leave the entries just to avoid too many > changes at this stage. They don't hurt anyone, and given Bernard's > if statement outside the switch, he'd have to make a not-so-easy change > to the code in order to remove them. > > Jari From owner-aaa-wg@merit.edu Sun Dec 29 23:47:11 2002 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 XAA07824 for ; Sun, 29 Dec 2002 23:47:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF38D912A8; Sun, 29 Dec 2002 23:50:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AB5E912A9; Sun, 29 Dec 2002 23:50:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74AC8912A8 for ; Sun, 29 Dec 2002 23:50:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F3E95DE2C; Sun, 29 Dec 2002 23:50:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 8C55D5DD94 for ; Sun, 29 Dec 2002 23:50:03 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBU4nD020808 for ; Mon, 30 Dec 2002 06:49:13 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 30 Dec 2002 06:50:01 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Dec 2002 06:50:00 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Dec 2002 06:50:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 396: BASE-16 NITS Date: Mon, 30 Dec 2002 06:49:59 +0200 Message-ID: Thread-Topic: [AAA-WG]: Issue 396: BASE-16 NITS Thread-Index: AcKuw9VV00FtPIJLRtSUt76FWSzSpgA+wL8w From: To: , X-OriginalArrivalTime: 30 Dec 2002 04:50:00.0482 (UTC) FILETIME=[E8D69820:01C2AFBE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA07824 Hi all, 11.3 updated to be aligned with 2.4. 2.10 fixed. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 28 December, 2002 23:44 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 396: BASE-16 NITS > > > Issue 396: BASE-16 Nits > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: December 28, 2002 > Reference: > Document: BASE-16 > Comment type: E > Priority: S > Section: Various > Rationale/Explanation of issue: > Section 2.4 > > > Diameter Common Messages 0 > NASREQ 1 [NASREQ] > Mobile-IP 2 [DIAMMIP] > Diameter Base Accounting 3 > Relay 0xffffffff > > Section 11.3 > > Diameter Base Accounting 0 > NASREQ 1 [NASREQ] > Mobile-IP 4 [DIAMMIP] > Relay 0xffffffff > > This seems to contradict section 2.4. > > Section 2.10 > > By authorizing a request, the home Diameter server > is implicitly indicating its willingness to engage in the business > transaction as specified by the contractual relationship between the > server and the previous hop? A DIAMETER_AUTHORIZATION_REJECTED error > message (see Section 7.1.5) is sent if the route traversed by the > request is unacceptable. > > > Remove the "?" > > > From owner-aaa-wg@merit.edu Tue Dec 31 07:49:25 2002 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 HAA22612 for ; Tue, 31 Dec 2002 07:49:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16CF1912D3; Tue, 31 Dec 2002 07:52:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC6D1912D4; Tue, 31 Dec 2002 07:52:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE5B7912D3 for ; Tue, 31 Dec 2002 07:52:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2BB85DF0C; Tue, 31 Dec 2002 07:52:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id BAE4E5DE37 for ; Tue, 31 Dec 2002 07:52:20 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBVCpT010770 for ; Tue, 31 Dec 2002 14:51:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 31 Dec 2002 14:49:55 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Dec 2002 14:49:53 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Dec 2002 14:49:53 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 31 Dec 2002 14:49:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for Review of RFC 2869bis Date: Tue, 31 Dec 2002 14:49:52 +0200 Message-ID: Thread-Topic: [AAA-WG]: Request for Review of RFC 2869bis Thread-Index: AcKkufTmy6l8VF/1TIejawuFAIcsDAMEOuQA From: To: , X-OriginalArrivalTime: 31 Dec 2002 12:49:52.0856 (UTC) FILETIME=[1CD7F580:01C2B0CB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA22612 Hi Bernard, I will read this over the next few days & send comments. I'm doing the same for NASREQ as well. John BTW - the margins are off on the 2869-bis. > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 16 December, 2002 05:09 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Request for Review of RFC 2869bis > > > RFC 2869 is in the process of being revised to provide > clarifications and > in order to address interoperability issues encountered with > RADIUS/EAP. > > The latest version (which will appear on the IETF archive shortly) is > available at: > > http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-05.txt > > Comments welcome. > > Since a good deal of the text in the Diameter EAP application > is shared > with RFC 2869bis, getting RFC 2869bis squared away will contribute to > completing Diameter EAP in a timely way. > > RFC 2869bis is a dependency of IEEE 802.1aa which is projected to be > issued as an IEEE standard in Spring 2003. In order to have > it issued as > an RFC in time to avoid delaying IEEE 802.1aa, the plan is to > bring it to > IETF last call in early 2003. > > >