From owner-aaa-wg@merit.edu Mon Jul 1 03:01: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 DAA03121 for ; Mon, 1 Jul 2002 03:01:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 122339120F; Mon, 1 Jul 2002 03:00:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19AF19125B; Mon, 1 Jul 2002 03:00:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A839C9120F for ; Mon, 1 Jul 2002 03:00:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EC925DDF9; Mon, 1 Jul 2002 03:00:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id E254F5DDDC for ; Mon, 1 Jul 2002 03:00:41 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6170VrU029210; Mon, 1 Jul 2002 09:00:31 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKRSDQV; Mon, 1 Jul 2002 09:00:31 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 09:00:31 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED2496@eestqnt104> X-Sybari-Trust: 9114f395 7216406a 0b6f7280 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'john.loughney@nokia.com'" , yohba@tari.toshiba.com, mccap@lucent.com Cc: aboba@internaut.com, tony.johansson@ericsson.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Mon, 1 Jul 2002 09:00:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-aaa-wg@merit.edu Precedence: bulk John, > > As I have understood, one of the reasons the IESG has for moving > to an experimental command code is to prevent common usage > of non-standard command codes. It is because interoperability > cannot be ensured when non-standard commands are used. > That is why we have there the Vendor-Id. If two vendors make use of the same command code, the Vendor-Id will allow to distinguish among them. The Vendor-Id creates separate namespaces. Where is there an interoperability problem? BR/Miguel From owner-aaa-wg@merit.edu Mon Jul 1 03:03: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 DAA03257 for ; Mon, 1 Jul 2002 03:03:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00A019125B; Mon, 1 Jul 2002 03:01:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 828449125C; Mon, 1 Jul 2002 03:01:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8D789125B for ; Mon, 1 Jul 2002 03:00:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 148A75DDDC; Mon, 1 Jul 2002 03:00:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 9EB8E5DDC2 for ; Mon, 1 Jul 2002 03:00:51 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6170lrU029302; Mon, 1 Jul 2002 09:00:47 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHMTZX13; Mon, 1 Jul 2002 09:00:47 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 09:00:46 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED2497@eestqnt104> X-Sybari-Trust: cce3f101 7216406a 0b6f7280 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Mon, 1 Jul 2002 09:00:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John, Isn't it simpler to leave it as it is, with the Vendor-ID in the header? Now, instead of a range of experimental command-codes, is the proposal to create a range of experimental application ids? With this change, we need interaction with IANA for something that won't be of general interest (vendor-specific extensions). BR/Miguel -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: domingo, 30 de junio de 2002 21:16 To: john.loughney@nokia.com; aaa-wg@merit.edu Subject: [AAA-WG]: Text needed for: Applicaiton ID in the header Hi all, Here is the text that I think is needed. There are some other places that need to be cleaned up as well. John 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- [some text] Application-ID Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See section 11.3 for the possible values that the application-id may use. The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message. 11.3 Application Identifiers As defined in section 2.4, the Application Identifier is used to identify a specific Diameter Application. There are standards-track application ids and vendor specific application ids. IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0xff00000000 - 0xfffffffe for vendor specific applications. Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. Vendor-Specific Application Identifiers, encoded in the Vendor-Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to the vendor's enterprise number, is for Private Use. Note that the Diameter protocol is not intended to be extended for any purpose. Any applications defined MUST ensure that they fit within the existing framework, and that no changes to the base protocol are required. From owner-aaa-wg@merit.edu Mon Jul 1 03:05:07 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 DAA03357 for ; Mon, 1 Jul 2002 03:05:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D40DC9125C; Mon, 1 Jul 2002 03:05:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 530A09125D; Mon, 1 Jul 2002 03:05:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3BA2A9125C for ; Mon, 1 Jul 2002 03:05:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0EB665DDDC; Mon, 1 Jul 2002 03:05:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 5AC425DDC2 for ; Mon, 1 Jul 2002 03:05:37 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6177QW12834 for ; Mon, 1 Jul 2002 10:07:26 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Jul 2002 10:05:32 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 10:05:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Vendor Command Code resolution Date: Mon, 1 Jul 2002 10:05:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655BE@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIgzRD5cotd1lF7RVaI1+C4Wehk8QAAHOHg From: To: Cc: X-OriginalArrivalTime: 01 Jul 2002 07:05:32.0577 (UTC) FILETIME=[B0C35110:01C220CD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Miquel, > The Vendor-Id creates separate namespaces. Where is there an > interoperability problem? There should not be two seperate namespaces. That is the point. There is one Interenet, if there are more than one namespaces, how can you insure that these namespaces could ever interoperate? John From owner-aaa-wg@merit.edu Mon Jul 1 03:11: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 DAA01328 for ; Mon, 1 Jul 2002 03:11:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D22CB9125D; Mon, 1 Jul 2002 03:12:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 098969125E; Mon, 1 Jul 2002 03:12:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03AA09125D for ; Mon, 1 Jul 2002 03:12:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF4D85DDDC; Mon, 1 Jul 2002 03:12:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id EDC985DDC2 for ; Mon, 1 Jul 2002 03:12:13 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g617Cgi21053 for ; Mon, 1 Jul 2002 10:12:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Jul 2002 10:12:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 10:12:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Mon, 1 Jul 2002 10:12:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E90@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIgzQpYgeNPQeWbSm6doe/gZ8GJdwAAK6Zg From: To: , X-OriginalArrivalTime: 01 Jul 2002 07:12:12.0725 (UTC) FILETIME=[9F450E50:01C220CE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01328 Hi Miguel, > Isn't it simpler to leave it as it is, with the Vendor-ID in > the header? Now, instead of a range of experimental > command-codes, is the proposal to create a range of > experimental application ids? One of the problems is that if we leave it the way it is, parsing of the Diameter messages will be quite hard, because you will need to dig into the AVP to find out what application the experimental command code is meant for. > With this change, we need interaction with IANA for something > that won't be of general interest (vendor-specific extensions). There is no way to ensure that any vendor-specific extenstion does not end up on the open Internet. The intent of the IETF is not to create seperate networks, but one network (i.e. - the Internet). Therefore, I think that the IESG feels that we to have mechanisms to ensure that when vendors extend protocols, there is at least some way to ensure some way to track what is being done. John From owner-aaa-wg@merit.edu Mon Jul 1 08:03: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 IAA29315 for ; Mon, 1 Jul 2002 08:03:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4242D9125E; Mon, 1 Jul 2002 08:04:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1608191261; Mon, 1 Jul 2002 08:04:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E49459125E for ; Mon, 1 Jul 2002 08:03:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C16895DE30; Mon, 1 Jul 2002 08:03:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.europe.nortel.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by segue.merit.edu (Postfix) with ESMTP id 069775DDC2 for ; Mon, 1 Jul 2002 08:03:48 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g61C3eQ03797; Mon, 1 Jul 2002 13:03:40 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 13:03:40 +0100 Message-ID: From: "Daniel Warren" To: "'john.loughney@nokia.com'" , Miguel-Angel.Pallares-Lopez@ece.ericsson.se Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Mon, 1 Jul 2002 13:03:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C220F7.51F777FE" 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_01C220F7.51F777FE Content-Type: text/plain; charset="iso-2022-jp" John Maybe it helps not to think of these as 'separate' but as 'parallel'. Vendor A might be identified by Vendor-Id 100 and allocate Command Codes 1, 2, 3, 4 to some of it's vendor specific commands. Vendor B has Vendor-Id 200 and allocates Command Codes 1, 2, 3, 4 to some it's different vendor specific commands. The fact that the command codes are the same is not a problem because the Vendor-Id distinguishes between them. If the Vendor-Id doesn't allow for the re-use of command codes for vendor-specific commands, what is it's purpose at all? Why include it in any discussion or anywhere in the specs? The point is that a private domain is created - saying that there is 'one internet' and enforcing this argument across the IETF would ultimately lead to removing private IP address spaces and mean you couldn't have NAT functions. It's a different scale but a similar principle. Dan -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: 01 July 2002 08:06 To: Miguel-Angel.Pallares-Lopez@ece.ericsson.se Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Vendor Command Code resolution Hi Miquel, > The Vendor-Id creates separate namespaces. Where is there an > interoperability problem? There should not be two seperate namespaces. That is the point. There is one Interenet, if there are more than one namespaces, how can you insure that these namespaces could ever interoperate? John ------_=_NextPart_001_01C220F7.51F777FE Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Vendor Command Code resolution

John

Maybe it helps not to think of these as 'separate' = but as 'parallel'.  Vendor A might be identified by Vendor-Id 100 = and allocate Command Codes 1, 2, 3, 4 to some of it's vendor specific = commands.  Vendor B has Vendor-Id 200 and allocates Command Codes = 1, 2, 3, 4 to some it's different vendor specific commands.  The = fact that the command codes are the same is not a problem because the = Vendor-Id distinguishes between them. 

If the Vendor-Id doesn't allow for the re-use of = command codes for vendor-specific commands, what is it's purpose at = all?  Why include it in any discussion or anywhere in the = specs?  The point is that a private domain is created - saying = that there is 'one internet' and enforcing this argument across the = IETF would ultimately lead to removing private IP address spaces and = mean you couldn't have NAT functions.  It's a different scale but = a similar principle.

Dan

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: 01 July 2002 08:06
To: = Miguel-Angel.Pallares-Lopez@ece.ericsson.se
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Vendor Command Code = resolution


Hi Miquel,

> The Vendor-Id creates separate namespaces. Where = is there an
> interoperability problem?

There should not be two seperate namespaces.  = That is the point.  There
is one Interenet, if there are more than one = namespaces, how can
you insure that these namespaces could ever = interoperate?

John

------_=_NextPart_001_01C220F7.51F777FE-- From owner-aaa-wg@merit.edu Mon Jul 1 09:18: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 JAA03675 for ; Mon, 1 Jul 2002 09:18:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9EC3991262; Mon, 1 Jul 2002 09:19:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7094191263; Mon, 1 Jul 2002 09:19:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92A2A91262 for ; Mon, 1 Jul 2002 09:18:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E6115DE12; Mon, 1 Jul 2002 09:18:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 1041F5DE04 for ; Mon, 1 Jul 2002 09:18:51 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 06:18:50 -0700 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com '" , "'aaa-wg@merit.edu '" Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Mon, 1 Jul 2002 06:18:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22101.D61353F0" 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_01C22101.D61353F0 Content-Type: text/plain; charset="iso-8859-1" Your proposed text does not state how a vendor gets a vendor specific application assigned by IANA. PatC -----Original Message----- From: john.loughney@nokia.com To: john.loughney@nokia.com; aaa-wg@merit.edu Sent: 6/30/2002 12:15 PM Subject: [AAA-WG]: Text needed for: Applicaiton ID in the header Hi all, Here is the text that I think is needed. There are some other places that need to be cleaned up as well. John 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- [some text] Application-ID Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See section 11.3 for the possible values that the application-id may use. The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message. 11.3 Application Identifiers As defined in section 2.4, the Application Identifier is used to identify a specific Diameter Application. There are standards-track application ids and vendor specific application ids. IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0xff00000000 - 0xfffffffe for vendor specific applications. Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. Vendor-Specific Application Identifiers, encoded in the Vendor-Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to the vendor's enterprise number, is for Private Use. Note that the Diameter protocol is not intended to be extended for any purpose. Any applications defined MUST ensure that they fit within the existing framework, and that no changes to the base protocol are required. ------_=_NextPart_001_01C22101.D61353F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Text needed for: Applicaiton ID in the = header

Your proposed text does not state how a vendor gets a = vendor specific application
assigned by IANA.

PatC

-----Original Message-----
From: john.loughney@nokia.com
To: john.loughney@nokia.com; aaa-wg@merit.edu
Sent: 6/30/2002 12:15 PM
Subject: [AAA-WG]: Text needed for: Applicaiton ID = in the header

Hi all,

Here is the text that I think is needed.  There = are some other
places that need to be cleaned up as well.

John

  = 0            = ;       = 1            = ;       = 2            = ;       3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
 |      = Ver      = |            = ;     Message = Length           =      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
 |R P E r r r r = r|           &nbs= p;      = Command-Code          =        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
 |         &n= bsp;           &n= bsp;   = Application-ID         &nbs= p;           &nbs= p;  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
 |         &n= bsp;            = Hop-by-Hop = Identifier          &n= bsp;         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
 |         &n= bsp;            = End-to-End = Identifier          &n= bsp;         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
 |  AVPs ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-


[some text]

   Application-ID

        Application-ID is four octets and is used to identify to which =
        application the message is applicable for.  The = application can
        be an = authentication application, an accounting application or a

        vendor = specific application.  See section 11.3 for the possible
        values = that the application-id may use. 

        The = application-id in the header MUST be the same as what is
contained
        in any = relevant AVPs contained in the message.


11.3  Application Identifiers

  As defined in section 2.4, the Application = Identifier is used to
identify
  a specific Diameter Application. There are = standards-track application
ids
  and vendor specific application ids.

  IANA [IANA] will assign the range 0x00000001 = to 0x00ffffff for
standards-track
  applications; and 0xff00000000 - 0xfffffffe = for vendor specific
applications.

  Both Application-Id and Acct-Application-Id = AVPs use the same
Application Identifier
  space.

  Vendor-Specific Application Identifiers, = encoded in the
Vendor-Specific-Application-Id
  Grouped AVP, with the Vendor-Id AVP set to = the vendor's enterprise
number, is for
  Private Use.

  Note that the Diameter protocol is not = intended to be extended for any
purpose.
  Any applications defined MUST ensure that = they fit within the existing
framework,
  and that no changes to the base protocol are = required.

------_=_NextPart_001_01C22101.D61353F0-- From owner-aaa-wg@merit.edu Mon Jul 1 09:25: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 JAA03972 for ; Mon, 1 Jul 2002 09:25:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 387DF91263; Mon, 1 Jul 2002 09:26:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 022D291265; Mon, 1 Jul 2002 09:26:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7E7F91263 for ; Mon, 1 Jul 2002 09:26:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3B545DDD3; Mon, 1 Jul 2002 09:26:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 284475DDD2 for ; Mon, 1 Jul 2002 09:26:28 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g61DQui27626 for ; Mon, 1 Jul 2002 16:26:56 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Jul 2002 16:26:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 16:26:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Mon, 1 Jul 2002 16:26:26 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E93@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIhAdjd0MZnZz9bQ7mXD22UQlrAIAAAAtGA From: To: , X-OriginalArrivalTime: 01 Jul 2002 13:26:27.0215 (UTC) FILETIME=[E73051F0:01C22102] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03972 Hi Pat, > Your proposed text does not state how a vendor gets a vendor specific application > assigned by IANA. That would be added in my proposal, if there is support. If we don't do this, then digging through this a bit more, I found a bug in the current base spec: 2.7 Realm-Based Routing Table All Realm-Based routing lookups are performed against what is commonly known as the Realm Routing Table (see section 12). A Realm Routing Table Entry contains the following fields: - Realm Name. This is the field that is typically used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match-from-the-right on the realm rather than requiring an exact match. - Application Identifier. An application is identified by a vendor id and an application id. For all IETF standards track Diameter applications, the vendor id is zero . A route entry can have a different destination based on the application identification avp of the message. This is one of Acct-Application-Id (for accounting messages), Auth-Application-Id (for non-accounting messages) or Vendor-Specific-Application-Id (for vendor specific messages). This field MUST be used as a secondary key field in routing table lookups. The text under Application ID seems to indicate that an Application ID is really 64 bits (Vendor ID + Application ID), in the case of an IETF standard application, the Vendor ID = 0. This is important to note, because currently, there is no provision to make Vendor Application IDs unique. Therefore, the realm routing table MUST keep track of the Vendor ID. Does it make sense to make this more explicit in the text? John From owner-aaa-wg@merit.edu Mon Jul 1 09:50:13 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 JAA05524 for ; Mon, 1 Jul 2002 09:50:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45C2F91265; Mon, 1 Jul 2002 09:50:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1979B91266; Mon, 1 Jul 2002 09:50:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E739491265 for ; Mon, 1 Jul 2002 09:50:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CDAFC5DE12; Mon, 1 Jul 2002 09:50:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 02E0E5DDD2 for ; Mon, 1 Jul 2002 09:50:42 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g61DpBi13519 for ; Mon, 1 Jul 2002 16:51:11 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 1 Jul 2002 16:50:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 16:50:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: draft-ietf-aaa-diameter-12.txt Date: Mon, 1 Jul 2002 16:50:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655E1@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIhAdjd0MZnZz9bQ7mXD22UQlrAIAAAAtGAAAEHQrA= From: To: X-OriginalArrivalTime: 01 Jul 2002 13:50:41.0826 (UTC) FILETIME=[4A345820:01C22106] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05524 Hi all, I have made changes to diameter and have a version here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt In this version, the header looks like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Which is needed to ensure proper lookup of application ID when doing message routing. I'd appreciate some feedback on this. I missed the draft cut-off, so we can still make some edits. John From owner-aaa-wg@merit.edu Mon Jul 1 10:23: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 KAA08542 for ; Mon, 1 Jul 2002 10:23:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB19491267; Mon, 1 Jul 2002 10:24:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94A9391268; Mon, 1 Jul 2002 10:24:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CF4B91267 for ; Mon, 1 Jul 2002 10:24:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C2BE5DE12; Mon, 1 Jul 2002 10:24:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1A7195DDF4 for ; Mon, 1 Jul 2002 10:24:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g61DWW928401; Mon, 1 Jul 2002 06:32:32 -0700 Date: Mon, 1 Jul 2002 06:32:32 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: pcalhoun@bstormnetworks.com, Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E93@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > That would be added in my proposal, if there is support. I think it's worth discussing what the choices are. It could be allocated by IANA on a first-come, first-served basis with no spec. This seems like the most reasonable to me. "Expert review with spec" seems inappropriate, since vendor-specific AVPs might be involved. Similarly, I don't think we can rope off portions of a 32-bit application-ID space for an SMI code. This is 24 bits, and so there would only be 8 bits left for the application, which is too small. > This is important to note, because currently, there is no provision to make Vendor > Application IDs unique. Therefore, the realm routing table MUST keep track of the > Vendor ID. I think that without making the Application ID unique, there is a problem, because this would mean that App-ID + Command Code would not uniquely identify the command. > Does it make sense to make this more explicit in the text? I think that some additional text is needed, yes. From owner-aaa-wg@merit.edu Mon Jul 1 10:35: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 KAA09305 for ; Mon, 1 Jul 2002 10:35:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3A0E9126F; Mon, 1 Jul 2002 10:35:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C88091279; Mon, 1 Jul 2002 10:35:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58A0A9126F for ; Mon, 1 Jul 2002 10:35:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E51D5DE30; Mon, 1 Jul 2002 10:35:43 -0400 (EDT) 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 1D3A15DDF4 for ; Mon, 1 Jul 2002 10:35:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17P2HG-000B9W-00; Mon, 01 Jul 2002 07:35:42 -0700 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]: Text needed for: Applicaiton ID in the header References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E93@esebe004.NOE.Nokia.com> Message-Id: Date: Mon, 01 Jul 2002 07:35:42 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit an underlying assumption of vendor-specific command codes in the 3gpp environment seems to be that the hosts using them are all from a single vendor. if this is true, then there is no other vendor's equipment interoperating. hence, there should be no need to identify a vendor-id, and the extended command codes should have no problems with not being unique to that vendor. and be careful not to tell me that they need to interoperate in a multi-vendor environment, as that's what standards are all about. randy From owner-aaa-wg@merit.edu Mon Jul 1 14:57: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 OAA26092 for ; Mon, 1 Jul 2002 14:57:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9BA9991212; Mon, 1 Jul 2002 14:57:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6577991282; Mon, 1 Jul 2002 14:57:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6361A91212 for ; Mon, 1 Jul 2002 14:57:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 52A665DE1E; Mon, 1 Jul 2002 14:57:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id ACF755DDF5 for ; Mon, 1 Jul 2002 14:57:43 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g61IwCi21322 for ; Mon, 1 Jul 2002 21:58:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 1 Jul 2002 21:57:42 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 21:57:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Mon, 1 Jul 2002 21:57:42 +0300 Message-ID: <9E3407CE45911B4097632389B77B202310792C@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIhDLCb2l4gJOIIRqWFBstDgy3HqAAH5w+A From: Cc: X-OriginalArrivalTime: 01 Jul 2002 18:57:42.0547 (UTC) FILETIME=[2DCF4E30:01C22131] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA26092 The assumption doesn't stand, because there is nothing preventing an operator to provide both 3G services and "classical" Internet services (or any other services making use of Diameter) to the same set of clients. If the resolution of the AAA server cannot be done based on application, then the only way to distinguish the services remains the static configuration of the network. Adrian -----Original Message----- From: ext Randy Bush [mailto:randy@psg.com] Sent: 01 July, 2002 17:36 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header an underlying assumption of vendor-specific command codes in the 3gpp environment seems to be that the hosts using them are all from a single vendor. if this is true, then there is no other vendor's equipment interoperating. hence, there should be no need to identify a vendor-id, and the extended command codes should have no problems with not being unique to that vendor. and be careful not to tell me that they need to interoperate in a multi-vendor environment, as that's what standards are all about. randy From owner-aaa-wg@merit.edu Mon Jul 1 15:43: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 PAA28963 for ; Mon, 1 Jul 2002 15:43:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9247591297; Mon, 1 Jul 2002 15:38:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9A45913A3; Mon, 1 Jul 2002 15:34:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CB3891396 for ; Mon, 1 Jul 2002 15:30:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DDD25DE2D; Mon, 1 Jul 2002 15:30:26 -0400 (EDT) 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 0A37B5DE27 for ; Mon, 1 Jul 2002 15:30:26 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17P6sT-000JVs-00; Mon, 01 Jul 2002 12:30:25 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header References: <9E3407CE45911B4097632389B77B202310792C@esebe014.NOE.Nokia.com> Message-Id: Date: Mon, 01 Jul 2002 12:30:25 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit i suspected as much. the operators will have gear from multiple vendors and running multiple applications. hence, we need to standardize all this stuff so that they all interoperate cleanly, and operators, aka users, have vendor independence. not a problem. that's what the ietf is all about and is why we all get the big bucks. randy --- > The assumption doesn't stand, because there is nothing preventing an > operator to provide both 3G services and "classical" Internet services > (or any other services making use of Diameter) to the same set of > clients. If the resolution of the AAA server cannot be done based on > application, then the only way to distinguish the services remains the > static configuration of the network. > > Adrian > > -----Original Message----- > From: ext Randy Bush [mailto:randy@psg.com] > Sent: 01 July, 2002 17:36 > To: Bernard Aboba > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header > > > an underlying assumption of vendor-specific command codes in the > 3gpp environment seems to be that the hosts using them are all from > a single vendor. if this is true, then there is no other vendor's > equipment interoperating. hence, there should be no need to > identify a vendor-id, and the extended command codes should have no > problems with not being unique to that vendor. > > and be careful not to tell me that they need to interoperate in a > multi-vendor environment, as that's what standards are all about. > > randy > From owner-aaa-wg@merit.edu Mon Jul 1 15:57: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 PAA29741 for ; Mon, 1 Jul 2002 15:57:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4AC44913E5; Mon, 1 Jul 2002 15:55:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 588C0913D2; Mon, 1 Jul 2002 15:53:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85130913E5 for ; Mon, 1 Jul 2002 15:52:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A2615DDF5; Mon, 1 Jul 2002 15:52:51 -0400 (EDT) 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 0352A5DDAB for ; Mon, 1 Jul 2002 15:52:51 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g61Jqk7N028593; Mon, 1 Jul 2002 15:52:47 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA15486; Mon, 1 Jul 2002 15:52:59 -0400 (EDT) Date: Mon, 1 Jul 2002 15:52:45 -0400 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-12.txt Message-ID: <20020701195244.GA651@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC655E1@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC655E1@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 78 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk I think the following (problematic) usages are still valid in -12 draft. Usage 1: Vendor A implements a vendor specific extention to NASREQ, by using experimental command codes with Vendor-ID assigned for Vendor A and Application-ID=1 (e.g., NASREQ). Usage 2: Vendor A requests IANA a new Application-ID for their own NASREQ extentions (say, Vendor-A-NASREQ) and implements a vendor specific extention to NASREQ, by using experimental command codes with Vendor-ID=0 and the new Application-ID. Note that without a professional review, IANA will just accept the request for a new Application-ID based on first-in-first-served policy. My point is that, if we try to pursure uniqueness of the experimental (and temporal) command code values among different vendors, there may be always a backdoor for a vendor to keep using their own extention to an existing application without standardizing the extention. IMHO, a better way is to define a truely temporary command code values that are exclusively assigned by IANA but have expiration date (e.g., two years after assignment). After the expiration date, the temporary command code values will be deleted from the IANA registry and reused for other temporary use after sometime. So standardization action is inevitable before the expiration date if the requester want to assign stable command code values for the temporary command codes. Given that, Vendor-ID and Application-ID are not needed in the Diameter header and it becomes simpler. But I could be wrong. Regards, Yoshihiro Ohba On Mon, Jul 01, 2002 at 04:50:41PM +0300, john.loughney@nokia.com wrote: > Hi all, > > I have made changes to diameter and have a version here: > > http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt > > > In this version, the header looks like this: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E r r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > Which is needed to ensure proper lookup of application ID when doing > message routing. > > I'd appreciate some feedback on this. > > I missed the draft cut-off, so we can still make some edits. > > John > From owner-aaa-wg@merit.edu Mon Jul 1 20:25:23 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 UAA10831 for ; Mon, 1 Jul 2002 20:25:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B857F9121F; Mon, 1 Jul 2002 20:25:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4F9C9129C; Mon, 1 Jul 2002 20:25:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02C6E9121F for ; Mon, 1 Jul 2002 20:25:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEB2F5DDFA; Mon, 1 Jul 2002 20:25:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 90C0C5DDF5 for ; Mon, 1 Jul 2002 20:25:49 -0400 (EDT) Received: from GWZW2K (sjc-vpn1-346.cisco.com [10.21.97.90]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA07291; Mon, 1 Jul 2002 17:25:41 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Randy Bush" , "Bernard Aboba" Cc: Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Mon, 1 Jul 2002 17:25:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush [mailto://randy@psg.com] writes: > an underlying assumption of vendor-specific command codes in the > 3gpp environment seems to be that the hosts using them are all from > a single vendor. I'm not sure where you that that idea from. The proposed VSCs of which I'm aware are 3GPP-specific; that is to say, they would only be used in a 3GPP environment. However, the 3GPP environment will certainly include equipment from many different vendors. > if this is true, then there is no other vendor's > equipment interoperating. hence, there should be no need to > identify a vendor-id, and the extended command codes should have no > problems with not being unique to that vendor. > > and be careful not to tell me that they need to interoperate in a > multi-vendor environment, as that's what standards are all about. Let's try for a little clarity here: the 3GPP VSCs would only be used in a 3GPP environment, and any equipment vendor wishing to sell into the 3GPP market would presumably need to demonstrate interoperability w/other vendors in that environment. In this case the "vendor" is an SDO (why, I'm not sure; maybe they believe that their app is very unique, maybe there is despair at getting what they need standardized in the IETF before 3G is obsolete). > > randy > > > From owner-aaa-wg@merit.edu Mon Jul 1 20:34: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 UAA11274 for ; Mon, 1 Jul 2002 20:34:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C4539129D; Mon, 1 Jul 2002 20:35:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCC6B9122A; Mon, 1 Jul 2002 20:33:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AF249129C for ; Mon, 1 Jul 2002 20:32:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 632DE5DE38; Mon, 1 Jul 2002 20:32:13 -0400 (EDT) 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 4108B5DDFA for ; Mon, 1 Jul 2002 20:32:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17PBaW-00016J-00; Mon, 01 Jul 2002 17:32:12 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Glen Zorn" Cc: "Bernard Aboba" , Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header References: Message-Id: Date: Mon, 01 Jul 2002 17:32:12 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> an underlying assumption of vendor-specific command codes in the >> 3gpp environment seems to be that the hosts using them are all from >> a single vendor. > I'm not sure where you that that idea from. The proposed VSCs of which I'm > aware are 3GPP-specific; that is to say, they would only be used in a 3GPP > environment. However, the 3GPP environment will certainly include equipment > from many different vendors. sounds like a need for standards. >> and be careful not to tell me that they need to interoperate in a >> multi-vendor environment, as that's what standards are all about. > Let's try for a little clarity here: the 3GPP VSCs would only be used in a > 3GPP environment, and any equipment vendor wishing to sell into the 3GPP > market would presumably need to demonstrate interoperability w/other vendors > in that environment. In this case the "vendor" is an SDO (why, I'm not > sure; maybe they believe that their app is very unique, maybe there is > despair at getting what they need standardized in the IETF before 3G is > obsolete). i doubt it is productibe to get into a slanging match with 3gpp about deployment and takeup rates vs. ietf document production rates. so let's all just do our jobs and chill. randy From owner-aaa-wg@merit.edu Mon Jul 1 21:49: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 VAA13168 for ; Mon, 1 Jul 2002 21:49:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 844FE912A8; Mon, 1 Jul 2002 21:50:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99367912A2; Mon, 1 Jul 2002 21:49:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B415912A3 for ; Mon, 1 Jul 2002 21:49:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 218215DE3A; Mon, 1 Jul 2002 21:49:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 96E645DDF5 for ; Mon, 1 Jul 2002 21:49:20 -0400 (EDT) Received: from GWZW2K (sjc-vpn1-346.cisco.com [10.21.97.90]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id SAA12294; Mon, 1 Jul 2002 18:49:13 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Randy Bush" Cc: "Bernard Aboba" , Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Mon, 1 Jul 2002 18:49:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush [mailto:randy@psg.com] writes: > >> an underlying assumption of vendor-specific command codes in the > >> 3gpp environment seems to be that the hosts using them are all from > >> a single vendor. > > I'm not sure where you that that idea from. The proposed VSCs > of which I'm > > aware are 3GPP-specific; that is to say, they would only be > used in a 3GPP > > environment. However, the 3GPP environment will certainly > include equipment > > from many different vendors. > > sounds like a need for standards. Agreed, but whose? 3GPP writes standards, too, and it's their standard that the vendors would need to follow (this may imply by reference IETF standards as well, of course). > > >> and be careful not to tell me that they need to interoperate in a > >> multi-vendor environment, as that's what standards are all about. > > Let's try for a little clarity here: the 3GPP VSCs would only > be used in a > > 3GPP environment, and any equipment vendor wishing to sell into the 3GPP > > market would presumably need to demonstrate interoperability > w/other vendors > > in that environment. In this case the "vendor" is an SDO (why, I'm not > > sure; maybe they believe that their app is very unique, maybe there is > > despair at getting what they need standardized in the IETF before 3G is > > obsolete). > > i doubt it is productibe to get into a slanging match with 3gpp about > deployment and takeup rates vs. ietf document production rates. I don't know too much about 3GPP, but I am quite familiar w/3GPP2. They have basically designed their network infrastructure around the functionality present in Diameter, including VSEs, having come to the wise conclusion that RADIUS was insufficient for the job. It's hard to deploy if you don't have the tools to do it. > so let's > all just do our jobs and chill. > > randy > > > From owner-aaa-wg@merit.edu Tue Jul 2 01:43: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 BAA17413 for ; Tue, 2 Jul 2002 01:43:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 36F9E912AD; Tue, 2 Jul 2002 01:44:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0075D912AE; Tue, 2 Jul 2002 01:44:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA3AC912AD for ; Tue, 2 Jul 2002 01:44:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABB6E5DDE6; Tue, 2 Jul 2002 01:44:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 11F385DD8D for ; Tue, 2 Jul 2002 01:44:26 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g625isi27425 for ; Tue, 2 Jul 2002 08:44:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Jul 2002 08:44:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 08:44:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: draft-ietf-aaa-diameter-12.txt Date: Tue, 2 Jul 2002 08:44:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655E6@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: draft-ietf-aaa-diameter-12.txt Thread-Index: AcIhPG4glxJiQu76R6O6IYYEvKJGvwATvK5w From: To: Cc: X-OriginalArrivalTime: 02 Jul 2002 05:44:24.0809 (UTC) FILETIME=[85C29D90:01C2218B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yoshihiro, > IMHO, a better way is to define a truely temporary command code values > that are exclusively assigned by IANA but have expiration date (e.g., > two years after assignment). After the expiration date, the temporary > command code values will be deleted from the IANA registry and reused > for other temporary use after sometime. So standardization action is > inevitable before the expiration date if the requester want to assign > stable command code values for the temporary command codes. Given > that, Vendor-ID and Application-ID are not needed in the Diameter > header and it becomes simpler. But I could be wrong. That could be a way forward - however, I've never requested such an IANA registry before. Do you have any suggestions on how to do this - any examples of this being done before? Thanks, John From owner-aaa-wg@merit.edu Tue Jul 2 02:05:10 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24466 for ; Tue, 2 Jul 2002 02:05:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D7004912AE; Tue, 2 Jul 2002 02:05:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A07EB912B1; Tue, 2 Jul 2002 02:05:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E3C4912AE for ; Tue, 2 Jul 2002 02:05:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 280B95DE3A; Tue, 2 Jul 2002 02:05:17 -0400 (EDT) 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 067BD5DD8D for ; Tue, 2 Jul 2002 02:05:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17PGmq-000ODh-00; Mon, 01 Jul 2002 23:05:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: , Subject: RE: [AAA-WG]: draft-ietf-aaa-diameter-12.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFC655E6@esebe004.NOE.Nokia.com> Message-Id: Date: Mon, 01 Jul 2002 23:05:16 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> IMHO, a better way is to define a truely temporary command code values >> that are exclusively assigned by IANA but have expiration date (e.g., >> two years after assignment). After the expiration date, the temporary >> command code values will be deleted from the IANA registry and reused >> for other temporary use after sometime. So standardization action is >> inevitable before the expiration date if the requester want to assign >> stable command code values for the temporary command codes. Given >> that, Vendor-ID and Application-ID are not needed in the Diameter >> header and it becomes simpler. But I could be wrong. > That could be a way forward - however, I've never requested such an IANA > registry before. Do you have any suggestions on how to do this - any > examples of this being done before? iana does temp assignments. but, documentation, i.e. rfc, has been required. before we go down this path, perhaps a bit of thought if this is the best strategy. randy From owner-aaa-wg@merit.edu Tue Jul 2 02:07: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 CAA26467 for ; Tue, 2 Jul 2002 02:07:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D09B4912B1; Tue, 2 Jul 2002 02:08:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2369912B3; Tue, 2 Jul 2002 02:08:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E69D912B1 for ; Tue, 2 Jul 2002 02:08:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EDB55DE3A; Tue, 2 Jul 2002 02:08:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 4684D5DD8D for ; Tue, 2 Jul 2002 02:08:11 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6268di09064 for ; Tue, 2 Jul 2002 09:08:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Jul 2002 09:08:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 09:08:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Tue, 2 Jul 2002 09:08:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E96@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIhDLBv5hQOpiFfQaG9IC7gfxj/NQAgFOVg From: To: , Cc: X-OriginalArrivalTime: 02 Jul 2002 06:08:10.0089 (UTC) FILETIME=[D74B1590:01C2218E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA26467 Hi Randy, > an underlying assumption of vendor-specific command codes in the > 3gpp environment seems to be that the hosts using them are all from > a single vendor. if this is true, then there is no other vendor's > equipment interoperating. hence, there should be no need to > identify a vendor-id, and the extended command codes should have no > problems with not being unique to that vendor. If life was only so simple. It seems that in the 3GPP case, the vendor is '3GPP'. All members implementing the 3GPP AAA application MUST conform to the 3GPP specs. > and be careful not to tell me that they need to interoperate in a > multi-vendor environment, as that's what standards are all about. From what I know, 3GPP is concerned about interoperability and do require vendors to be able to demonstrate interoperability (I don't know what kind of mechanisms they have in place for this). As vendors & carriers are all involved in this process in 3GPP, it may be enough for 3GPP specific networks - but I think we need to bring the 3GPP specifications into the IETF to ensure interoperability with the Internet. I think we just need a good plan on how to do this. John From owner-aaa-wg@merit.edu Tue Jul 2 02:08:02 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 CAA26487 for ; Tue, 2 Jul 2002 02:08:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0653D912B3; Tue, 2 Jul 2002 02:08:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3E74912B5; Tue, 2 Jul 2002 02:08:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51061912B3 for ; Tue, 2 Jul 2002 02:08:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3EE335DD8D; Tue, 2 Jul 2002 02:08:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 8D5D35DE3A for ; Tue, 2 Jul 2002 02:08:31 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g626AOW02889 for ; Tue, 2 Jul 2002 09:10:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Jul 2002 09:08:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 09:08:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: draft-ietf-aaa-diameter-12.txt Date: Tue, 2 Jul 2002 09:08:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655EA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: draft-ietf-aaa-diameter-12.txt Thread-Index: AcIhjnvnNN4BYW/dTumzitq0rFYR3QAAF80Q From: To: Cc: , X-OriginalArrivalTime: 02 Jul 2002 06:08:30.0557 (UTC) FILETIME=[E37E40D0:01C2218E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA26487 Hi Randy, > iana does temp assignments. but, documentation, i.e. rfc, has been > required. before we go down this path, perhaps a bit of thought if > this is the best strategy. I agree. John From owner-aaa-wg@merit.edu Tue Jul 2 02:34: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 CAA26782 for ; Tue, 2 Jul 2002 02:34:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6862C912B5; Tue, 2 Jul 2002 02:34:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3956912B6; Tue, 2 Jul 2002 02:34:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5DCF912B5 for ; Tue, 2 Jul 2002 02:34:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A78A75DE4A; Tue, 2 Jul 2002 02:34:37 -0400 (EDT) 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 862215DD8D for ; Tue, 2 Jul 2002 02:34:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17PHFF-0000uw-00; Mon, 01 Jul 2002 23:34:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: , Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E96@esebe004.NOE.Nokia.com> Message-Id: Date: Mon, 01 Jul 2002 23:34:37 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> an underlying assumption of vendor-specific command codes in the >> 3gpp environment seems to be that the hosts using them are all from >> a single vendor. if this is true, then there is no other vendor's >> equipment interoperating. hence, there should be no need to >> identify a vendor-id, and the extended command codes should have no >> problems with not being unique to that vendor. > > If life was only so simple. It seems that in the 3GPP case, the > vendor is '3GPP'. All members implementing the 3GPP AAA application > MUST conform to the 3GPP specs. ok. but i do not see how this alters my argument. s/vendor/3gpp/ > As vendors & carriers are all involved in this process in 3GPP, it > may be enough for 3GPP specific networks - but I think we need to > bring the 3GPP specifications into the IETF to ensure interoperability > with the Internet. I think we just need a good plan on how to do this. agreed. randy From owner-aaa-wg@merit.edu Tue Jul 2 02:39:06 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 CAA26840 for ; Tue, 2 Jul 2002 02:39:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 118FC912B6; Tue, 2 Jul 2002 02:39:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D52C6912B7; Tue, 2 Jul 2002 02:39:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB5DF912B6 for ; Tue, 2 Jul 2002 02:39:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B40A65DE4A; Tue, 2 Jul 2002 02:39:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 4820A5DD8D for ; Tue, 2 Jul 2002 02:39:31 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g626dMrU029647; Tue, 2 Jul 2002 08:39:22 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHM41AKT; Tue, 2 Jul 2002 08:39:22 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 08:39:22 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED24AC@eestqnt104> X-Sybari-Trust: 0257bfc0 7216406a 0b6f7280 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'gwz@cisco.com'" , Randy Bush Cc: Bernard Aboba , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Tue, 2 Jul 2002 08:39:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > > > >> an underlying assumption of vendor-specific command codes in the > > >> 3gpp environment seems to be that the hosts using them > are all from > > >> a single vendor. > > > I'm not sure where you that that idea from. The proposed VSCs > > of which I'm > > > aware are 3GPP-specific; that is to say, they would only be > > used in a 3GPP > > > environment. However, the 3GPP environment will certainly > > include equipment > > > from many different vendors. > > > > sounds like a need for standards. > > Agreed, but whose? 3GPP writes standards, too, and it's > their standard that > the vendors would need to follow (this may imply by reference > IETF standards > as well, of course). > 3GPP's. What 3GPP have done is to make use of a feature offered by the protocol up to base-11, namely VSEs. I would like to clarify that they have been fully respectful with the base protocol; that is, no changes/additions/deletions, only decisions on some "MAYs", e.g. they use SCTP and not TCP as transport. 3GPP VSEs will only be used in a 3GPP environment. Interoperability between 3GPP compliant equipment (even from different manufacturers) is guaranteed by conformance with the 3GPP specifications. If a peer claims support of a determined 3GPP VSE, it will have to do so in compliance with the corresponding 3GPP specifications. Nothing in the base protocol precludes that a piece of equipment implements a 3GPP VSE (or in general a manufacturer VSE) and at the same time one or more IETF standard extensions and connect to other peer supporting the same or different extensions. There are mechanisms already in place in the base protocol that allow interoperability: - The capabilities exchange mechanism. - The ability to reject commands not recognised/supported. - The ability to reject mandatory AVPs not recognised/supported. BR/Miguel From owner-aaa-wg@merit.edu Tue Jul 2 03:16:00 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27305 for ; Tue, 2 Jul 2002 03:15:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0922912B7; Tue, 2 Jul 2002 03:12:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01555912B8; Tue, 2 Jul 2002 03:11:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DECE91235 for ; Tue, 2 Jul 2002 03:05:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAEBD5DE4D; Tue, 2 Jul 2002 03:05:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 4E3745DE4A for ; Tue, 2 Jul 2002 03:05:53 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6275nRb014428; Tue, 2 Jul 2002 09:05:49 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHM412LR; Tue, 2 Jul 2002 09:05:49 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 09:05:49 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED24AD@eestqnt104> X-Sybari-Trust: 2150292e 7216406a 0b6f7280 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'Randy Bush'" , john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Tue, 2 Jul 2002 09:05:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > >> an underlying assumption of vendor-specific command codes in the > >> 3gpp environment seems to be that the hosts using them are all from > >> a single vendor. if this is true, then there is no other vendor's > >> equipment interoperating. hence, there should be no need to > >> identify a vendor-id, and the extended command codes should have no > >> problems with not being unique to that vendor. > > > > If life was only so simple. It seems that in the 3GPP case, the > > vendor is '3GPP'. All members implementing the 3GPP AAA application > > MUST conform to the 3GPP specs. > > ok. but i do not see how this alters my argument. s/vendor/3gpp/ > 3GPP has been granted a "SMI Network Management Private Enterprise Codes" value by IANA. From the point of view of the protocol, a message carrying a Vendor-Id will allow a peer to know in which scope the received command should be processed. > > As vendors & carriers are all involved in this process in 3GPP, it > > may be enough for 3GPP specific networks - but I think we need to > > bring the 3GPP specifications into the IETF to ensure > interoperability > > with the Internet. I think we just need a good plan on how > to do this. > > agreed. You know this, this is just for the record. The effort that 3GPP did during year 2001 was to put in place, better, to introduce in an existing draft (draft-calhoun-sip-aaa-reqs-03), the requirements that the 3GPP architecture were imposing for the interactions between SIP servers and a AAA infrastruture. Comments were given by the AD to that draft in the sense that it was too solution oriented. In paralell, draft-johansson-diameter-mm-app implemented the requirements compiled in that draft as an extension to Diameter. The work load in AAA WG at that time (early year 2002) and the fact that the requirements draft was not yet a working group item in SIPPING prevented this draft to progress further in the AAA WG. 3GPP's final intention was to refer to this draft (once RFCed). As close as we were to the closure of the Release-5 in 3GPP, considering that 3GPP already had a "Vendor-Id" we had no choice but to make use of the feature of the base protocol an implement our extension as a VSE, being respectful with the base protocol as we had done during the preparation of the rest of the drafts. Currently, and following ADs advice of not producing a requirements draft so solution oriented, a new one has been prepared, draft-loughney-sip-aaa-req. It will be 3GPP's intention that this draft includes 3GPP's requirements. 3GPP are aware that the functionality offered by the protocol obtained as a result of this work may not be identical to the current 3GPP VSE. As a result of the IETF, it is expected that this protocol will solve problems more generic than the ones that the 3GPP VSE deals with. It is assumed that some of the requirements from 3GPP may not be of general interest and may not be part of the final protocol implementation. Only in that situation may 3GPP eventually require some mechanism to perform some vendor-specific adaptations. However, this doesn't mean that the mechanism that the base protocol currently offers to create VSEs can be something provisional, as has been discussed in the list these days. The protocol has to be robust enough to cope with the potential interoperability problems that the introduction of this mechanism may create - some of us think that it is already good enough. BR/Miguel From owner-aaa-wg@merit.edu Tue Jul 2 09:11: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 JAA07691 for ; Tue, 2 Jul 2002 09:11:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73719912BE; Tue, 2 Jul 2002 09:11:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44F62912C0; Tue, 2 Jul 2002 09:11:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F30A912BE for ; Tue, 2 Jul 2002 09:11:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B1D95DE2D; Tue, 2 Jul 2002 09:11:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id D76195DD8E for ; Tue, 2 Jul 2002 09:11:50 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 06:11:48 -0700 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com '" , "'randy@psg.com '" , "'aboba@internaut.com '" Cc: "'aaa-wg@merit.edu '" Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Tue, 2 Jul 2002 06:11:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C221CA.032F3110" 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_01C221CA.032F3110 Content-Type: text/plain; charset="iso-8859-1" > As vendors & carriers are all involved in this process in 3GPP, it > may be enough for 3GPP specific networks - but I think we need to > bring the 3GPP specifications into the IETF to ensure interoperability > with the Internet. I think we just need a good plan on how to do this. And of what value would this be to 3GPP? What are the chances that the IETF rubber stamps their spec without any modifications? How willing to change their "blessed" standard from comments received from folks in the IETF? Seems like a nightmare situation to me :( PatC ------_=_NextPart_001_01C221CA.032F3110 Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: Text needed for: Applicaiton ID in the header

> As vendors & carriers are all involved in this process in 3GPP, it
> may be enough for 3GPP specific networks - but I think we need to
> bring the 3GPP specifications into the IETF to ensure interoperability
> with the Internet.  I think we just need a good plan on how to do this.

And of what value would this be to 3GPP? What are the chances that the IETF
rubber stamps their spec without any modifications? How willing to change their
"blessed" standard from comments received from folks in the IETF?

Seems like a nightmare situation to me :(

PatC

------_=_NextPart_001_01C221CA.032F3110-- From owner-aaa-wg@merit.edu Tue Jul 2 11:32: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 LAA22592 for ; Tue, 2 Jul 2002 11:32:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB7C891205; Tue, 2 Jul 2002 11:32:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F4EE91231; Tue, 2 Jul 2002 11:32:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C807591205 for ; Tue, 2 Jul 2002 11:32:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD91B5DE63; Tue, 2 Jul 2002 11:32:11 -0400 (EDT) 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 833335DE69 for ; Tue, 2 Jul 2002 11:32:11 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17PPdR-00018s-00; Tue, 02 Jul 2002 08:32:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Miguel-Angel Pallares-Lopez Cc: gwz@cisco.com, Bernard Aboba , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header References: <577066326047D41180AC00508B955DDA05ED24AC@eestqnt104> Message-Id: Date: Tue, 02 Jul 2002 08:32:09 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 3GPP's. What 3GPP have done is to make use of a feature offered > by the protocol up to base-11, namely VSEs. I would like to > clarify that they have been fully respectful with the base > protocol; that is, no changes/additions/deletions, only decisions > on some "MAYs", e.g. they use SCTP and not TCP as transport. yup. we left a loophole (which had a bug report filed against it 18 months ago), and 3gpp had the poor design taste [0] to crawl through it. now that we're through assessing blame, the useful question is how we crawl out of this mess to dry ground. this devolves into a few sub-questions. o how do we help 3gpp get 5 out the door without digging a deeper hole? o how do we clean up the hole so no one else falls into it? o how do we help 3gpp and others understand how to meet their needs for 6 when the hole is not there. what we don't need to do is figure out how to furnish the hole with overstuffed chairs and an espresso machine. well, maybe we keep the espresso machine :-) randy --- [0] - note that they did ask for our design help, and we could have avoided this by helping them. the problem was (and is) that spending the resources to do so would have further delayed progress on our already long-delayed docs, which are our primary task. if we don't get a good spec done, we will spend the next decade helping one user community at a time through the swamp we have allowed. i.e. we will have failed at our primary task. From owner-aaa-wg@merit.edu Tue Jul 2 11:48: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 LAA23767 for ; Tue, 2 Jul 2002 11:48:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D63A9124C; Tue, 2 Jul 2002 11:49:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AA1C912CE; Tue, 2 Jul 2002 11:49:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B6199124C for ; Tue, 2 Jul 2002 11:47:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 131DB5DE65; Tue, 2 Jul 2002 11:47:24 -0400 (EDT) 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 A55275DE63 for ; Tue, 2 Jul 2002 11:47:23 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g62FktSB020291; Tue, 2 Jul 2002 11:46:55 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA18473; Tue, 2 Jul 2002 11:47:08 -0400 (EDT) Date: Tue, 2 Jul 2002 11:46:54 -0400 To: john.loughney@nokia.com Cc: yohba@tari.toshiba.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-12.txt Message-ID: <20020702154654.GB4208@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC655E6@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC655E6@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 38 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk According to RFC 2434, number allocation policy is basically determined by IANA Consideration Section in RFCs, not by IANA. So, I think IANA is flexible to support various kinds of assignment policies. So, just defining a new assignment policy, e.g, "First Come First Served with Time Constraint" policy and describing it in "IANA Consideration Section" of the Diameter base specification should work. Note that the suggested assignment policies are just for a specific command code space. For "standard" command code space, "Standards Action" MUST be applied, of course. In addition, we can also hold the current experimental (or private) command code values for which no interoperability is guaranteed at any time. "Private Use" policy can be applied for this. Yoshihiro Ohba On Tue, Jul 02, 2002 at 08:44:23AM +0300, john.loughney@nokia.com wrote: > Hi Yoshihiro, > > > IMHO, a better way is to define a truely temporary command code values > > that are exclusively assigned by IANA but have expiration date (e.g., > > two years after assignment). After the expiration date, the temporary > > command code values will be deleted from the IANA registry and reused > > for other temporary use after sometime. So standardization action is > > inevitable before the expiration date if the requester want to assign > > stable command code values for the temporary command codes. Given > > that, Vendor-ID and Application-ID are not needed in the Diameter > > header and it becomes simpler. But I could be wrong. > > That could be a way forward - however, I've never requested such an IANA > registry before. Do you have any suggestions on how to do this - any > examples of this being done before? > > Thanks, > John > From owner-aaa-wg@merit.edu Tue Jul 2 13:27: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 NAA02806 for ; Tue, 2 Jul 2002 13:27:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50258912D3; Tue, 2 Jul 2002 13:27:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12EBF912D9; Tue, 2 Jul 2002 13:27:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56142912D3 for ; Tue, 2 Jul 2002 13:27:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 44E3D5DE64; Tue, 2 Jul 2002 13:27:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 22CB65DE24 for ; Tue, 2 Jul 2002 13:27:09 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020702172706.VLWI10398.fep02-svc.swip.net@ipunplugged.com>; Tue, 2 Jul 2002 19:27:06 +0200 Message-ID: <3D21E2FC.4080503@ipunplugged.com> Date: Tue, 02 Jul 2002 19:29:32 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Text needed for: Applicaiton ID in the header References: <577066326047D41180AC00508B955DDA05ED24AC@eestqnt104> 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 Randy, Please, for the love of God, offer one single technical argument why the notion of VSEs is so horrible. Your phobic behaviour and adamant refusal to explain yourself to the wg aren't nearly as convincing as one might think. Please stick with solid technical terminology, specifically, refrain from using colourful metaphors. Another issue is that your calls for IETF process being demanded by others are not quite convincing when you yourself side-step the wg the first chance you get. Your demand has not exactly been met with enthusiasm by the wg. Nobody seems to be able to find your "bug report" and if it was such a show stopper, why didn't anyone follow up on it for 18 months? I will be happy to help getting rid of "the hole" once you explain why it is a hole and not a foundation upon which to build wonderful things. j Randy Bush wrote: >>3GPP's. What 3GPP have done is to make use of a feature offered >>by the protocol up to base-11, namely VSEs. I would like to >>clarify that they have been fully respectful with the base >>protocol; that is, no changes/additions/deletions, only decisions >>on some "MAYs", e.g. they use SCTP and not TCP as transport. >> >> > >yup. we left a loophole (which had a bug report filed against it >18 months ago), and 3gpp had the poor design taste [0] to crawl >through it. now that we're through assessing blame, the useful >question is how we crawl out of this mess to dry ground. this >devolves into a few sub-questions. > > o how do we help 3gpp get 5 out the door without digging a deeper > hole? > > o how do we clean up the hole so no one else falls into it? > > o how do we help 3gpp and others understand how to meet their > needs for 6 when the hole is not there. > >what we don't need to do is figure out how to furnish the hole >with overstuffed chairs and an espresso machine. well, maybe we >keep the espresso machine :-) > >randy > >--- > >[0] - note that they did ask for our design help, and we could have > avoided this by helping them. the problem was (and is) that > spending the resources to do so would have further delayed > progress on our already long-delayed docs, which are our > primary task. if we don't get a good spec done, we will > spend the next decade helping one user community at a time > through the swamp we have allowed. i.e. we will have failed > at our primary task. > > > From owner-aaa-wg@merit.edu Wed Jul 3 04:59: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 EAA01973 for ; Wed, 3 Jul 2002 04:59:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC70C91211; Wed, 3 Jul 2002 04:59:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 985579123A; Wed, 3 Jul 2002 04:59:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5949991211 for ; Wed, 3 Jul 2002 04:59:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F1D65DDA0; Wed, 3 Jul 2002 04:59:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 96D8A5DD8C for ; Wed, 3 Jul 2002 04:59:50 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 228DB6A907; Wed, 3 Jul 2002 11:59:46 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 118A36A906; Wed, 3 Jul 2002 11:59:44 +0300 (EEST) Message-ID: <3D22BD5E.7070908@kolumbus.fi> Date: Wed, 03 Jul 2002 12:01:18 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'john.loughney@nokia.com '" Cc: "Pat R. Calhoun" , "'randy@psg.com '" , "'aboba@internaut.com '" , "'aaa-wg@merit.edu '" Subject: Re: [AAA-WG]: Text needed for: Applicaiton ID in the header References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, > As vendors & carriers are all involved in this process in 3GPP, it > may be enough for 3GPP specific networks - but I think we need to > bring the 3GPP specifications into the IETF to ensure interoperability > with the Internet. I think we just need a good plan on how to do this. That's a nice goal. But on closer look, I'm really unsure what it means. Let's think about possible meanings of your words "interoperability with the Internet" above: 1. It means that the 3GPP specifications MUST use the base protocol as it is, don't break the protocol, etc. [And as Miguel pointed out, 3GPP is being a good citizen by doing this.] 2. It means that the 3GPP specifications MUST NOT have any other features than those already available in the "Internet". For instance, if the IETF specifications only support dial-in authentication, then 3GPP should not offer anything else than dial-in authentication. [I hope we are not debating about this.] 3. It means that the 3GPP specifications can have new features, but those features MUST be released in a lock-step with the IETF, and both parties MUST run the full standardization process through before the result is usable. For instance, shouldn't release a multimedia system before there's a standard IETF multimedia AAA protocol. [Hmm...] 4. It means that the 3GPP specifications can have new features even before they are IETF standards, but we need a transition plan to get back to a single standard by the time IETF produces a specification of the same thing. [E.g., multimedia aaa.] It seems to me that we, the WG and other SDOs have been assuming model 1 is good enough. It also looks to me that Randy would like to be in model 3, but he realizes the time pressures and wants to allow model 4 [forgive me if I didn't read you correctly]. So, what should we do? I think this debate is less about the specific technical mechanisms than the higher-level approach. I actually think the original Diameter VSC and VSA rules are excellent technical solutions. They also work very well if one assumes that many different AAA applications are really needed. If one assumes that only few applications are needed and fears that there will be competing vendor-specific schemes even for these applications -- then they might not be perfect. I think the WG still follows the former assumption, and would like to have model 1. However, if we take the latter assumption and try to establish model 4, then one way to deal with the above concerns is to retain the original protocol mechanisms, but add a rule that VSCs that do not belong to a IANA registry MUST NOT be accepted i.e. lead to a specific error code. Then the rules for the IANA registry will be something like "Expert Review, resulting in a registration with a specific lifetime". This would ensure that apps developed due to temporary lack of an internet standard would time out, and the standard would replace the VSCs later. The lifetimes need to take in account the time to develop an internet standard for the thing AND the time needed to upgrade all the equipment in the network to support this new standard. Finally, it would be good to have text that says new Diameter implementations MUST support an Internet standard Diameter extension, if the standard is available AND they support an earlier VSC for the same application. This is needed during the transition period. Jari From owner-aaa-wg@merit.edu Wed Jul 3 07:34: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 HAA06430 for ; Wed, 3 Jul 2002 07:34:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02C63912D9; Wed, 3 Jul 2002 07:35:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C01E5912DA; Wed, 3 Jul 2002 07:35:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95FD9912D9 for ; Wed, 3 Jul 2002 07:35:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 76ABF5DD94; Wed, 3 Jul 2002 07:35:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id ADE945DD8C for ; Wed, 3 Jul 2002 07:35:03 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g63BZVi03445 for ; Wed, 3 Jul 2002 14:35:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Jul 2002 14:35:05 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 14:35:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Diameter Base: Application ID proposal Date: Wed, 3 Jul 2002 14:35:01 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65610@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIhCvLM5ubIBfv7SyWMPl2v3+QwSgBeinEQ From: To: Cc: , X-OriginalArrivalTime: 03 Jul 2002 11:35:02.0472 (UTC) FILETIME=[AB98FC80:01C22285] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06430 Hi all, Reviewing the current spec, I think it is important to make the Application ID unique, across IETF standards and Vendor Applications. What this means is that there would be an IANA registry which would work on a first come, first serve basis. In the IANA registry, there would be a field to state the vendor and contact person. In the case of an IETF standard application, this would reduce down to IETF & the RFC number. Does this sound reasonable? This would be aid message routing greatly. Comments? John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 01 July, 2002 16:33 > To: Loughney John (NRC/Helsinki) > Cc: pcalhoun@bstormnetworks.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header > > > > That would be added in my proposal, if there is support. > > I think it's worth discussing what the choices are. It could > be allocated > by IANA on a first-come, first-served basis with no spec. This seems > like the most reasonable to me. "Expert review with spec" seems > inappropriate, since vendor-specific AVPs might be involved. > > Similarly, I don't think we can rope off portions of a 32-bit > application-ID > space for an SMI code. This is 24 bits, and so there would > only be 8 bits > left for the application, which is too small. > > > This is important to note, because currently, there is no > provision to make Vendor > > Application IDs unique. Therefore, the realm routing table > MUST keep track of the > > Vendor ID. > > I think that without making the Application ID unique, there > is a problem, > because this would mean that App-ID + Command Code would not uniquely > identify the command. > > > Does it make sense to make this more explicit in the text? > > I think that some additional text is needed, yes. > > From owner-aaa-wg@merit.edu Wed Jul 3 09:33: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 JAA12603 for ; Wed, 3 Jul 2002 09:33:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB743912DC; Wed, 3 Jul 2002 09:34:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA8E2912DD; Wed, 3 Jul 2002 09:34:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F16EA912DC for ; Wed, 3 Jul 2002 09:33:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D06F95DDD0; Wed, 3 Jul 2002 09:33:07 -0400 (EDT) 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 69A325DD8C for ; Wed, 3 Jul 2002 09:33:07 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g63DWiSB019900; Wed, 3 Jul 2002 09:32:45 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA21097; Wed, 3 Jul 2002 09:32:55 -0400 (EDT) Date: Wed, 3 Jul 2002 09:32:40 -0400 To: john.loughney@nokia.com Cc: aboba@internaut.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Base: Application ID proposal Message-ID: <20020703133240.GA615@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65610@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65610@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 78 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 03, 2002 at 02:35:01PM +0300, john.loughney@nokia.com wrote: > Hi all, > > Reviewing the current spec, I think it is important to make > the Application ID unique, across IETF standards and > Vendor Applications. What this means is that there would > be an IANA registry which would work on a first come, first > serve basis. In the IANA registry, there would be a field > to state the vendor and contact person. In the case of an > IETF standard application, this would reduce down to IETF & > the RFC number. Does this sound reasonable? > This would be aid message routing greatly. I think it's necessary, but I'm not sure it's sufficient. When a vendor uses a Vendor-Specific-Application-ID with specifying their Vendor-ID and a standard Auth-Application-Id, e.g., (NASREQ), it would be problematic if that vendor application could be something different from the Diameter NASREQ application and that is going to be widely used for a long time without being standardized. Instead of that, is it possible to eliminate Vendor-Specific-Application-ID (i.e., just using {Auth,Acct}-Application-Id without accompaning a Vendor-ID) and partition the Application Identifier number space into three categories for which different number assignment policy is applied, i.e., "standard", "temporary" and "private use", like I suggested for Command-Code? What do you think? Yoshihiro Ohba > > Comments? > > John > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 01 July, 2002 16:33 > > To: Loughney John (NRC/Helsinki) > > Cc: pcalhoun@bstormnetworks.com; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header > > > > > > > That would be added in my proposal, if there is support. > > > > I think it's worth discussing what the choices are. It could > > be allocated > > by IANA on a first-come, first-served basis with no spec. This seems > > like the most reasonable to me. "Expert review with spec" seems > > inappropriate, since vendor-specific AVPs might be involved. > > > > Similarly, I don't think we can rope off portions of a 32-bit > > application-ID > > space for an SMI code. This is 24 bits, and so there would > > only be 8 bits > > left for the application, which is too small. > > > > > This is important to note, because currently, there is no > > provision to make Vendor > > > Application IDs unique. Therefore, the realm routing table > > MUST keep track of the > > > Vendor ID. > > > > I think that without making the Application ID unique, there > > is a problem, > > because this would mean that App-ID + Command Code would not uniquely > > identify the command. > > > > > Does it make sense to make this more explicit in the text? > > > > I think that some additional text is needed, yes. > > > > > From owner-aaa-wg@merit.edu Wed Jul 3 09:36:02 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 JAA12799 for ; Wed, 3 Jul 2002 09:36:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C32F912DD; Wed, 3 Jul 2002 09:36:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D5C5912DE; Wed, 3 Jul 2002 09:36:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F898912DD for ; Wed, 3 Jul 2002 09:36:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D5075DDD0; Wed, 3 Jul 2002 09:36:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 92DCC5DD8C for ; Wed, 3 Jul 2002 09:36:36 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g63CijT22246; Wed, 3 Jul 2002 05:44:45 -0700 Date: Wed, 3 Jul 2002 05:44:45 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: pcalhoun@bstormnetworks.com, Subject: Re: [AAA-WG]: Diameter Base: Application ID proposal In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65610@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk There are two distinct issues here: a) Desire to make the app-ID unique for capabilities negotiation. b) Desire to make command + ? unique in the case of "experimental" commands. So based on problem a) alone, it would seem that making the app-ID unique makes sense. Problem b) is somewhat distinct, and whether ? = app-ID depends on how "experimental" commands are allocated. For example, if the "experimental" commands are allocated uniquely by IANA, then I think we don't also need the app-ID to uniquify the command code. However, if there is a small experimental command space that can be reused for multiple uses, then to prevent conflicts, then command + app-ID needs to be unique. Note that whatever uniquifies the command needs to be put into the Diameter header, so that it won't be necessary to parse AVPs to figure out what the command is. I'd also note that making app-id + command unique implies that a new application reusing standard commands could change the definition of standard commands. That might argue for allocation of "experimental" commands by IANA, so that the command alone would be unique, the app-ID wouldn't be needed in the header, and a new application couldn't redefine the meaning of existing standard commands. On Wed, 3 Jul 2002 john.loughney@nokia.com wrote: > Hi all, > > Reviewing the current spec, I think it is important to make > the Application ID unique, across IETF standards and > Vendor Applications. What this means is that there would > be an IANA registry which would work on a first come, first > serve basis. In the IANA registry, there would be a field > to state the vendor and contact person. In the case of an > IETF standard application, this would reduce down to IETF & > the RFC number. Does this sound reasonable? > This would be aid message routing greatly. > > Comments? > > John > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 01 July, 2002 16:33 > > To: Loughney John (NRC/Helsinki) > > Cc: pcalhoun@bstormnetworks.com; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header > > > > > > > That would be added in my proposal, if there is support. > > > > I think it's worth discussing what the choices are. It could > > be allocated > > by IANA on a first-come, first-served basis with no spec. This seems > > like the most reasonable to me. "Expert review with spec" seems > > inappropriate, since vendor-specific AVPs might be involved. > > > > Similarly, I don't think we can rope off portions of a 32-bit > > application-ID > > space for an SMI code. This is 24 bits, and so there would > > only be 8 bits > > left for the application, which is too small. > > > > > This is important to note, because currently, there is no > > provision to make Vendor > > > Application IDs unique. Therefore, the realm routing table > > MUST keep track of the > > > Vendor ID. > > > > I think that without making the Application ID unique, there > > is a problem, > > because this would mean that App-ID + Command Code would not uniquely > > identify the command. > > > > > Does it make sense to make this more explicit in the text? > > > > I think that some additional text is needed, yes. > > > > > From owner-aaa-wg@merit.edu Wed Jul 3 11:45: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 LAA18858 for ; Wed, 3 Jul 2002 11:45:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C07F3912DE; Wed, 3 Jul 2002 11:15:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 892F4912E0; Wed, 3 Jul 2002 11:15:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F29B912DE for ; Wed, 3 Jul 2002 11:15:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1BC715DE12; Wed, 3 Jul 2002 11:15:58 -0400 (EDT) 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 1E67A5DD8C for ; Wed, 3 Jul 2002 11:15:53 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g63FFXSB029653; Wed, 3 Jul 2002 11:15:33 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA21465; Wed, 3 Jul 2002 11:15:44 -0400 (EDT) Date: Wed, 3 Jul 2002 11:15:30 -0400 To: Jari Arkko Cc: "'john.loughney@nokia.com '" , "Pat R. Calhoun" , "'randy@psg.com '" , "'aboba@internaut.com '" , "'aaa-wg@merit.edu '" Subject: Re: [AAA-WG]: Text needed for: Applicaiton ID in the header Message-ID: <20020703151530.GD615@catfish> References: <3D22BD5E.7070908@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3D22BD5E.7070908@kolumbus.fi> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 79 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, On Wed, Jul 03, 2002 at 12:01:18PM +0300, Jari Arkko wrote: > Hi John, > > 4. It means that the 3GPP specifications can have new features even before > they > are IETF standards, but we need a transition plan to get back to a single > standard by the time IETF produces a specification of the same thing. > [E.g., > multimedia aaa.] I have a transition plan in my mind. During the transition period, just assigning two different values for the same command name, i.e., one is assigned from the temporal space and another is assigned from the standard space, and the implementation interprets both values as that command name. Very simple. An issue is how long the transition period should be. Not too long not to short. I believe this is the win-win solution between IETF and other SDOs, and the VSC approach does not outperform this approach in terms of interoperability. (VSA is different, I agree that we need VSA to carry vendor-specific information and does not affect interoperability so much.) > > It seems to me that we, the WG and other SDOs have been assuming model 1 is > good > enough. It also looks to me that Randy would like to be in model 3, but he > realizes > the time pressures and wants to allow model 4 [forgive me if I didn't read > you > correctly]. > > So, what should we do? I think this debate is less about the specific > technical > mechanisms than the higher-level approach. I actually think the original > Diameter > VSC and VSA rules are excellent technical solutions. They also work very > well > if one assumes that many different AAA applications are really needed. If > one > assumes that only few applications are needed and fears that there will be > competing > vendor-specific schemes even for these applications -- then they might not > be perfect. > > I think the WG still follows the former assumption, and would like to have > model 1. > However, if we take the latter assumption and try to establish model 4, > then one > way to deal with the above concerns is to retain the original protocol > mechanisms, > but add a rule that VSCs that do not belong to a IANA registry MUST NOT be > accepted > i.e. lead to a specific error code. Then the rules for the IANA registry > will be > something like "Expert Review, resulting in a registration with a specific > lifetime". > This would ensure that apps developed due to temporary lack of an internet > standard > would time out, and the standard would replace the VSCs later. The > lifetimes need > to take in account the time to develop an internet standard for the thing > AND the time needed to upgrade all the equipment in the network to support > this > new standard. Finally, it would be good to have text that says new Diameter > implementations > MUST support an Internet standard Diameter extension, if the standard is > available AND > they support an earlier VSC for the same application. This is needed during > the > transition period. > > Jari > > Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Jul 3 17:01: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 RAA06360 for ; Wed, 3 Jul 2002 17:01:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D01F1912EA; Wed, 3 Jul 2002 16:53:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F824912EC; Wed, 3 Jul 2002 16:53:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89A2D912EA for ; Wed, 3 Jul 2002 16:53:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 684005DE6C; Wed, 3 Jul 2002 16:53:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id D51695DE09 for ; Wed, 3 Jul 2002 16:53:01 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-142.cisco.com [10.21.64.142]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA18356; Wed, 3 Jul 2002 13:52:54 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Nenad Trifunovic" Cc: "Bernard Aboba" , "AAA WG" Subject: [AAA-WG]: RE: Issue w/issue 308 Date: Wed, 3 Jul 2002 13:52:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <0GYO00FZWRQL0P@pmismtp05.wcomnet.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nenad Trifunovic [mailto:nenad.trifunovic@wcom.com] writes: > I am not sure what the issue is. The issue is that the values in issue 308 don't match the ANSI values; so the question is, will the issue be resolved in your opinion if only the ANSI values are used in our document? Also, although you registered the RADIUS attribute before RFC 2865 was published, it might be a nice idea to publish an RFC describing it (as is required by the IANA considerations section of RFC 2865. > The operational use of the value > is what seems to matter the most. One can use ITU or ANSI > values, all the same to me as long as developers have a reliable > and easily accessable (not quite true for either ITU or ANSI docs) > document which clearly explains what particular value is used for. > > Regards, > nenad > > > >Date: Sun, 23 Jun 2002 16:04 -0700 (PDT) > >From: Glen Zorn > >To: Bernard Aboba , > > Nenad.Trifunovic@wcom.com > >CC: AAA WG > >Reply-to: gwz@cisco.com > >Importance: High > >Subject: Issue w/issue 308 > > > >I am working to resolve this issue with the NASREQ doc, & have run into a > >bit of a snag: the values listed in the issue for the proposed > >Originating-Line-Info AVP do not even come close to matching > those listed in > >Annex C of ANSI T1.113-2000 for the SS7 Originating Line Information > >parameter field. I'm assuming that we want to include only the > ANSI values? > > > > > > From owner-aaa-wg@merit.edu Thu Jul 4 00:24:08 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 AAA27696 for ; Thu, 4 Jul 2002 00:24:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 440069122C; Thu, 4 Jul 2002 00:24:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19ECC91230; Thu, 4 Jul 2002 00:24:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E375C9122C for ; Thu, 4 Jul 2002 00:24:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA52B5DEB4; Thu, 4 Jul 2002 00:24:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 7488B5DDBF for ; Thu, 4 Jul 2002 00:24:28 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g644Ovi00214 for ; Thu, 4 Jul 2002 07:24:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 07:24:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 07:24:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter Base: Application ID proposal Date: Thu, 4 Jul 2002 07:24:25 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65615@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter Base: Application ID proposal Thread-Index: AcIipE33EGYpXDpGQkSvTqE4mNZTdwAbgKQg From: To: Cc: , X-OriginalArrivalTime: 04 Jul 2002 04:24:26.0792 (UTC) FILETIME=[AEBED280:01C22312] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA27696 Hi Bernard, > There are two distinct issues here: > > a) Desire to make the app-ID unique for capabilities negotiation. > b) Desire to make command + ? unique in the case of "experimental" > commands. > > So based on problem a) alone, it would seem that making the > app-ID unique makes sense. Agreed. > Problem b) is somewhat distinct, and whether ? = app-ID depends on how > "experimental" commands are allocated. For example, if the "experimental" > commands are allocated uniquely by IANA, then I think we don't also need > the app-ID to uniquify the command code. However, if there is a small > experimental command space that can be reused for multiple > uses, then to prevent conflicts, then command + app-ID needs to be unique. I think it is the later, a re-usable experimental range of command codes are probably useful. > Note that whatever uniquifies the command needs to be put into the > Diameter header, so that it won't be necessary to parse AVPs > to figure out what the command is. Agreed. > I'd also note that making app-id + command unique implies that a new > application reusing standard commands could change the definition of > standard commands. That might argue for allocation of "experimental" > commands by IANA, so that the command alone would be unique, the app-ID > wouldn't be needed in the header, and a new application couldn't redefine > the meaning of existing standard commands. I am not so sure if this is needed or not. I would worry that if I am testing a new possible (experimental) application then I should register the new commands, even if the experiment fails. John From owner-aaa-wg@merit.edu Thu Jul 4 02:54: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 CAA09723 for ; Thu, 4 Jul 2002 02:54:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13DE291230; Thu, 4 Jul 2002 02:55:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9FE29123F; Thu, 4 Jul 2002 02:55:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB6F991230 for ; Thu, 4 Jul 2002 02:55:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A11225DEC3; Thu, 4 Jul 2002 02:55:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 674C55DEC2 for ; Thu, 4 Jul 2002 02:55:27 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 3C23A6A905; Thu, 4 Jul 2002 09:55:21 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AE4AE6A904; Thu, 4 Jul 2002 09:54:50 +0300 (EEST) Message-ID: <3D23F197.7050305@kolumbus.fi> Date: Thu, 04 Jul 2002 09:56:23 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Base: Application ID proposal References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65615@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with what John is saying below. >>So based on problem a) alone, it would seem that making the >>app-ID unique makes sense. >> > > Agreed. > > >>Problem b) is somewhat distinct, and whether ? = app-ID depends on how >>"experimental" commands are allocated. For example, if the "experimental" >>commands are allocated uniquely by IANA, then I think we don't also need >>the app-ID to uniquify the command code. However, if there is a small >>experimental command space that can be reused for multiple >>uses, then to prevent conflicts, then command + app-ID needs to be unique. >> > > I think it is the later, a re-usable experimental range of command codes > are probably useful. > > >>Note that whatever uniquifies the command needs to be put into the >>Diameter header, so that it won't be necessary to parse AVPs >>to figure out what the command is. >> > > Agreed. > > >>I'd also note that making app-id + command unique implies that a new >>application reusing standard commands could change the definition of >>standard commands. That might argue for allocation of "experimental" >>commands by IANA, so that the command alone would be unique, the app-ID >>wouldn't be needed in the header, and a new application couldn't redefine >>the meaning of existing standard commands. >> > > I am not so sure if this is needed or not. I would worry that if I > am testing a new possible (experimental) application then I should > register the new commands, even if the experiment fails. > > John > > From owner-aaa-wg@merit.edu Thu Jul 4 04:25: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 EAA11357 for ; Thu, 4 Jul 2002 04:25:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBBF091240; Thu, 4 Jul 2002 04:25:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 974FE912ED; Thu, 4 Jul 2002 04:25:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CE6B91240 for ; Thu, 4 Jul 2002 04:25:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 541DE5DE02; Thu, 4 Jul 2002 04:25:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id A91AC5DD8F for ; Thu, 4 Jul 2002 04:25:50 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g648QKi18350 for ; Thu, 4 Jul 2002 11:26:20 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 11:25:49 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:25:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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 proposal Date: Thu, 4 Jul 2002 11:25:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E9F@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter Base: Application ID proposal Thread-Index: AcIili1lATnAKXVPQlq2Z07iwIhfpwAnYhNw From: To: Cc: X-OriginalArrivalTime: 04 Jul 2002 08:25:49.0378 (UTC) FILETIME=[670A1220:01C22334] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yoshihiro, > When a vendor uses a Vendor-Specific-Application-ID with specifying > their Vendor-ID and a standard Auth-Application-Id, e.g., (NASREQ), it > would be problematic if that vendor application could be something > different from the Diameter NASREQ application and that is going to be > widely used for a long time without being standardized. > > Instead of that, is it possible to eliminate > Vendor-Specific-Application-ID (i.e., just using > {Auth,Acct}-Application-Id without accompaning a Vendor-ID) and > partition the Application Identifier number space into three > categories for which different number assignment policy is applied, > i.e., "standard", "temporary" and "private use", like I suggested for > Command-Code? My plan is that the application id would be unique, no matter if it is vendor specific, standardized IETF, accounting, authorization, etc. This way, the application id by itself would be unique. John From owner-aaa-wg@merit.edu Thu Jul 4 04:28: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 EAA11420 for ; Thu, 4 Jul 2002 04:28:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41E6B912ED; Thu, 4 Jul 2002 04:29:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06DB5912EE; Thu, 4 Jul 2002 04:29:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF937912ED for ; Thu, 4 Jul 2002 04:29:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEAAB5DE02; Thu, 4 Jul 2002 04:29:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 129E15DD8F for ; Thu, 4 Jul 2002 04:29:03 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g648UuW27551 for ; Thu, 4 Jul 2002 11:30:57 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 11:28:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:28:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Text needed for: Applicaiton ID in the header Date: Thu, 4 Jul 2002 11:28:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65629@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIipXymM7QmDAmyTAioxZkpwKlnYgAjvQzQ From: To: Cc: X-OriginalArrivalTime: 04 Jul 2002 08:28:58.0178 (UTC) FILETIME=[D792AA20:01C22334] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yoshihiro, > I have a transition plan in my mind. During the transition period, > just assigning two different values for the same command name, i.e., > one is assigned from the temporal space and another is assigned from > the standard space, and the implementation interprets both values > as that command name. Very simple. An issue is how long the > transition period should be. Not too long not to short. > > I believe this is the win-win solution between IETF and other SDOs, > and the VSC approach does not outperform this approach in terms of > interoperability. (VSA is different, I agree that we need VSA to > carry vendor-specific information and does not affect interoperability > so much.) This actually will be more complicated in reality. What I think is a good plan is to allow experimental command codes, which are not assumed to be unique. Use of these experimental commands do not guarantee interoperability and are meant for experimentation. See: http://www.ietf.org/internet-drafts/draft-narten-iana-experimental-allocations-01.txt for more detail. John From owner-aaa-wg@merit.edu Thu Jul 4 09:47: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 JAA17242 for ; Thu, 4 Jul 2002 09:47:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 10A8991208; Thu, 4 Jul 2002 09:48:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEA1B9120E; Thu, 4 Jul 2002 09:48:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E60091208 for ; Thu, 4 Jul 2002 09:47:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 940145DEAB; Thu, 4 Jul 2002 09:47:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id BCD015DD8F for ; Thu, 4 Jul 2002 09:47:46 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g64DneW07701 for ; Thu, 4 Jul 2002 16:49:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Jul 2002 16:47:45 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 16:47:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Text needed for: Applicaiton ID in the header Date: Thu, 4 Jul 2002 16:47:44 +0300 Message-ID: <9E3407CE45911B4097632389B77B2023C850EB@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIipXymM7QmDAmyTAioxZkpwKlnYgAjvQzQAAspgWA= From: Cc: X-OriginalArrivalTime: 04 Jul 2002 13:47:45.0367 (UTC) FILETIME=[60441670:01C22361] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit If the Application-Id is unique and in the header, is the Vendor-Id needed anymore in the header? Adrian -----Original Message----- From: ext [mailto:john.loughney@nokia.com] Sent: 04 July, 2002 11:29 To: yohba@tari.toshiba.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Hi Yoshihiro, > I have a transition plan in my mind. During the transition period, > just assigning two different values for the same command name, i.e., > one is assigned from the temporal space and another is assigned from > the standard space, and the implementation interprets both values > as that command name. Very simple. An issue is how long the > transition period should be. Not too long not to short. > > I believe this is the win-win solution between IETF and other SDOs, > and the VSC approach does not outperform this approach in terms of > interoperability. (VSA is different, I agree that we need VSA to > carry vendor-specific information and does not affect interoperability > so much.) This actually will be more complicated in reality. What I think is a good plan is to allow experimental command codes, which are not assumed to be unique. Use of these experimental commands do not guarantee interoperability and are meant for experimentation. See: http://www.ietf.org/internet-drafts/draft-narten-iana-experimental-allocations-01.txt for more detail. John From owner-aaa-wg@merit.edu Thu Jul 4 09:51: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 JAA17327 for ; Thu, 4 Jul 2002 09:51:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95B309120E; Thu, 4 Jul 2002 09:52:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6389091211; Thu, 4 Jul 2002 09:52:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B60A9120E for ; Thu, 4 Jul 2002 09:52:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45A795DEB7; Thu, 4 Jul 2002 09:52:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 86C355DD8F for ; Thu, 4 Jul 2002 09:52:06 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g64Dqai22180 for ; Thu, 4 Jul 2002 16:52:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Jul 2002 16:52:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 16:52:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Text needed for: Applicaiton ID in the header Date: Thu, 4 Jul 2002 16:52:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6564A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIipXymM7QmDAmyTAioxZkpwKlnYgAjvQzQAAspgWAAADbZgA== From: To: Cc: X-OriginalArrivalTime: 04 Jul 2002 13:52:05.0435 (UTC) FILETIME=[FB4750B0:01C22361] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Adrian, > If the Application-Id is unique and in the header, is the > Vendor-Id needed anymore in the header? That is the proposal. John From owner-aaa-wg@merit.edu Thu Jul 4 10:06:12 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 KAA17623 for ; Thu, 4 Jul 2002 10:06:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02F6F91211; Thu, 4 Jul 2002 10:06:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB07791230; Thu, 4 Jul 2002 10:06:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE9A591211 for ; Thu, 4 Jul 2002 10:06:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9ECE85DE20; Thu, 4 Jul 2002 10:06:38 -0400 (EDT) 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 3F6A25DDA6 for ; Thu, 4 Jul 2002 10:06:38 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g64E6USB027684; Thu, 4 Jul 2002 10:06:30 -0400 (EDT) Received: from localhost (tari.research.telcordia.com [207.3.232.66]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA24196; Thu, 4 Jul 2002 10:06:42 -0400 (EDT) Date: Thu, 4 Jul 2002 10:06:27 -0400 To: john.loughney@nokia.com Cc: yohba@tari.toshiba.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Text needed for: Applicaiton ID in the header Message-ID: <20020704140627.GA1473@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65629@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65629@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 38 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk John, On Thu, Jul 04, 2002 at 11:28:56AM +0300, john.loughney@nokia.com wrote: > This actually will be more complicated in reality. What I think is a good > plan is to allow experimental command codes, which are not assumed > to be unique. Use of these experimental commands do not guarantee > interoperability and are meant for experimentation. See: http://www.ietf.org/internet-drafts/draft-narten-iana-experimental-allocations-01.txt for more detail. > The following is your entire suggestion for experimental implementation: 1. Use of non-unique experimental command codes 2. Use of unique application identifiers 3. Making application identifiers + experimental command codes to be unique (as mentioned by Bernard) As I mentioned earlier, doing something similar to 3) can always be a backdoor for experimental implementation to stay long without a standardization process. It seems to me this is essentially equivalent to just replacing the word "Vendor-ID" with "Application-ID" and I'm afraid this would be rejected by IESG again unless the IESG just does not like the word "vendor specific" :) Note that my proposal is a bit different from the temporary assignments described in draft-narten-iana-experimental-allocations-01.txt in that there is no explicit number returning action is necessary in my proposal, just expires just like Internet-Drafts. So the same drawbacks of the temporary assignments do not necessarity hold for my proposal, I think. But needs more detailed discussion. > John > Thanks, Yoshihiro Ohba From owner-aaa-wg@merit.edu Thu Jul 4 15:05: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 PAA23021 for ; Thu, 4 Jul 2002 15:05:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D29F912EF; Thu, 4 Jul 2002 15:05:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A765912F1; Thu, 4 Jul 2002 15:05:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D4E3912EF for ; Thu, 4 Jul 2002 15:05:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CEDE5DECE; Thu, 4 Jul 2002 15:05:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id C9AB75DEB7 for ; Thu, 4 Jul 2002 15:05:45 -0400 (EDT) Received: from GWZW2K (sjc-vpn2-140.cisco.com [10.21.112.140]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id MAA05774; Thu, 4 Jul 2002 12:05:41 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Cc: Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Thu, 4 Jul 2002 12:05:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEFC6564A@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Hi Adrian, > > > If the Application-Id is unique and in the header, is the > > Vendor-Id needed anymore in the header? > > That is the proposal. Maybe I'm missing something here. The IESG is apparently complaining (I say "apparently" because, despite several requests for technical explanation, none has been forthcoming) about VSEs. How, exactly, does this proposal solve this problem? > > John > > From owner-aaa-wg@merit.edu Fri Jul 5 02:14: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 CAA12752 for ; Fri, 5 Jul 2002 02:14:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 33A59912FC; Fri, 5 Jul 2002 02:14:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEA32912FD; Fri, 5 Jul 2002 02:14:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C286A912FC for ; Fri, 5 Jul 2002 02:14:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A29915DE26; Fri, 5 Jul 2002 02:14:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CB6105DDE2 for ; Fri, 5 Jul 2002 02:14:34 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g656F4i16587 for ; Fri, 5 Jul 2002 09:15:04 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Jul 2002 09:14:37 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 09:14:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Text needed for: Applicaiton ID in the header Date: Fri, 5 Jul 2002 09:14:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65653@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIjjczu0Nk+TdhoTh69CSCZDWey4gAXNp5A From: To: , Cc: X-OriginalArrivalTime: 05 Jul 2002 06:14:33.0660 (UTC) FILETIME=[3B289FC0:01C223EB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Glen, > > > If the Application-Id is unique and in the header, is the > > > Vendor-Id needed anymore in the header? > > > > That is the proposal. > > Maybe I'm missing something here. The IESG is apparently complaining (I say > "apparently" because, despite several requests for technical explanation, > none has been forthcoming) about VSEs. How, exactly, does this proposal > solve this problem? As far as I understand, the complaint is not about vendor specific extentions, but only vender specific command codes. As near as I can tell, VSCs could be problematic as they directly affect interoperability with 'standard' implentations (i.e. - you need to have the code to support VSCs; VSCs are not advertised; etc.). The proposal is to allow a small range of re-usable experimental command codes. These codes would be uniquely identifiable by application id + experimental command code. Side affects are: 1) Application ID is needed in the Diameter header for efficient processing 2) Application ID should be unique, even for vendor specific applications 3) Vendor ID is not be needed in the Diameter Header then. Does this cause any technical problems for anyone? John From owner-aaa-wg@merit.edu Fri Jul 5 06:48:26 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 GAA18216 for ; Fri, 5 Jul 2002 06:48:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB40A91244; Fri, 5 Jul 2002 06:49:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6D5391300; Fri, 5 Jul 2002 06:49:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C23091244 for ; Fri, 5 Jul 2002 06:49:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53C415DD98; Fri, 5 Jul 2002 06:49:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.europe.nortel.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by segue.merit.edu (Postfix) with ESMTP id 8C3BF5DD97 for ; Fri, 5 Jul 2002 06:49:01 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65AmZd20961; Fri, 5 Jul 2002 11:48:35 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <3CJ1F1RN>; Fri, 5 Jul 2002 11:48:35 +0100 Message-ID: From: "Daniel Warren" To: "'john.loughney@nokia.com'" , gwz@cisco.com, Adrian.Constantin@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Fri, 5 Jul 2002 11:48:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22411.82D72BFE" 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_01C22411.82D72BFE Content-Type: text/plain; charset="iso-2022-jp" > Side affects are: > 1) Application ID is needed in the Diameter header for efficient processing > 2) Application ID should be unique, even for vendor specific applications > 3) Vendor ID is not be needed in the Diameter Header then. > >Does this cause any technical problems for anyone? Not trying to be argumentative but can someone explain how this is better than;- 1) Vendor ID is needed in the Diameter header for efficient processing (servers that don't recognise the Vendor-Id dismiss the application/command). 2) Vendor ID is ALREADY unique and registered with IANA, and exists today 3) Application does not need to be unique and can be allocated by the vendor, because of point 1. ... which I think is what we have now... Dan ------_=_NextPart_001_01C22411.82D72BFE Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Text needed for: Applicaiton ID in the = header

> Side affects are: 
>       1) Application = ID is needed in the Diameter header for efficient processing
>       2) = Application ID should be unique, even for vendor specific = applications
>       3) Vendor = ID is not be needed in the Diameter Header then.
>
>Does this cause any technical problems for = anyone?

Not trying to be argumentative but can someone = explain how this is better than;-
        1) Vendor = ID is needed in the Diameter header for efficient processing (servers = that don't recognise the Vendor-Id dismiss the = application/command).

        2) Vendor = ID is ALREADY unique and registered with IANA, and exists today
        3) = Application does not need to be unique and can be allocated by the = vendor, because of point 1.

... which I think is what we have now...

Dan

------_=_NextPart_001_01C22411.82D72BFE-- From owner-aaa-wg@merit.edu Fri Jul 5 06:52: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 GAA18310 for ; Fri, 5 Jul 2002 06:52:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6BF6B91300; Fri, 5 Jul 2002 06:53:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3705591301; Fri, 5 Jul 2002 06:53:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2168E91300 for ; Fri, 5 Jul 2002 06:53:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0563B5DD98; Fri, 5 Jul 2002 06:53:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 30AAF5DD97 for ; Fri, 5 Jul 2002 06:53:03 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g65ArWi04262 for ; Fri, 5 Jul 2002 13:53:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Jul 2002 13:53:05 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 13:53:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Text needed for: Applicaiton ID in the header Date: Fri, 5 Jul 2002 13:53:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EA9@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIkEYcu4sIasEZqSYmASz5zKHcsSQAAArDg From: To: , , Cc: X-OriginalArrivalTime: 05 Jul 2002 10:53:01.0791 (UTC) FILETIME=[21FB16F0:01C22412] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dan, > Not trying to be argumentative but can someone explain how this is better than;- > 1) Vendor ID is needed in the Diameter header for efficient processing (servers that don't recognise the Vendor-Id dismiss the application/command). > 2) Vendor ID is ALREADY unique and registered with IANA, and exists today > 3) Application does not need to be unique and can be allocated by the vendor, because of point 1. > ... which I think is what we have now... A single Vendor ID could be applicable for multiple application IDs. A vendor might make multiple applications. 3GPP has at least 2 applications, I think ... Since the experimental command code could exist in multiple applications, the Vendor ID in the header does not provide uniqueness for the experimental command code. Therefore, since the experimental command is tied to an application id, but not to a vendor id, I see no way in which a vendor id would provide any useful information for message routing. John From owner-aaa-wg@merit.edu Fri Jul 5 07:54:19 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 HAA20194 for ; Fri, 5 Jul 2002 07:54:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A61B591247; Fri, 5 Jul 2002 07:54:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71BA591301; Fri, 5 Jul 2002 07:54:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61A2D91247 for ; Fri, 5 Jul 2002 07:54:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4896F5DD97; Fri, 5 Jul 2002 07:54:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id C71275DD8F for ; Fri, 5 Jul 2002 07:54:52 -0400 (EDT) Received: from fmorn1dcode948i (a3.local.ipunplugged.com [192.168.4.173]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g65BsxUg010433; Fri, 5 Jul 2002 13:55:00 +0200 From: "Fredrik Johansson" To: , , Cc: Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Fri, 5 Jul 2002 13:55:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65653@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On > Behalf Of john.loughney@nokia.com > Sent: den 5 juli 2002 08:15 > To: gwz@cisco.com; Adrian.Constantin@nokia.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header > > > Hi Glen, > > > > > If the Application-Id is unique and in the header, is the > > > > Vendor-Id needed anymore in the header? > > > > > > That is the proposal. > > > > Maybe I'm missing something here. The IESG is apparently > complaining (I say > > "apparently" because, despite several requests for technical > explanation, > > none has been forthcoming) about VSEs. How, exactly, does this proposal > > solve this problem? > > As far as I understand, the complaint is not about vendor > specific extentions, > but only vender specific command codes. As near as I can tell, VSCs could > be problematic as they directly affect interoperability with 'standard' > implentations (i.e. - you need to have the code to support VSCs; VSCs are > not advertised; etc.). Yes they are if we do as Glen said and demand that when adding VSC you have to have a new application id (vendor specific). BTW, I can't understand why we bother to put all this energy to find a workaround to something that's not a problem. We should instead focus on getting the iesg to explain why this has to be changed. Since randy refuses to answer the question, is there anyone else that we can talk to? /fredrik > > The proposal is to allow a small range of re-usable experimental > command codes. > These codes would be uniquely identifiable by application id + > experimental > command code. > > Side affects are: > 1) Application ID is needed in the Diameter header for > efficient processing > 2) Application ID should be unique, even for vendor > specific applications > 3) Vendor ID is not be needed in the Diameter Header then. > > Does this cause any technical problems for anyone? > > John From owner-aaa-wg@merit.edu Fri Jul 5 08:57: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 IAA22738 for ; Fri, 5 Jul 2002 08:57:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7267291303; Fri, 5 Jul 2002 08:57:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4594D91305; Fri, 5 Jul 2002 08:57:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BECF91303 for ; Fri, 5 Jul 2002 08:57:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B7A55DDA8; Fri, 5 Jul 2002 08:57:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.europe.nortel.com (h33s128a211n47.user.nortelnetworks.com [47.211.128.33]) by segue.merit.edu (Postfix) with ESMTP id 540775DD97 for ; Fri, 5 Jul 2002 08:57:36 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g65CvOZ19299; Fri, 5 Jul 2002 13:57:24 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <3CJ1FJS1>; Fri, 5 Jul 2002 13:57:24 +0100 Message-ID: From: "Daniel Warren" To: "'john.loughney@nokia.com'" , gwz@cisco.com, Adrian.Constantin@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header Date: Fri, 5 Jul 2002 13:57:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22423.81BD489A" 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_01C22423.81BD489A Content-Type: text/plain; charset="iso-2022-jp" > Hi Dan, > > > > Not trying to be argumentative but can someone explain how this is better than;- > > 1) Vendor ID is needed in the Diameter header for efficient processing (servers > that don't recognise the Vendor-Id dismiss the application/command). > > 2) Vendor ID is ALREADY unique and registered with IANA, and exists today > > 3) Application does not need to be unique and can be allocated by the vendor, > because of point 1. > > ... which I think is what we have now... > > A single Vendor ID could be applicable for multiple application IDs. A vendor > might make multiple applications. 3GPP has at least 2 applications, > I think ... > If the device looks at the Vendor Id and doesn't recognise it, then it can dismiss the application and commands without further processing. The point of having the Vendor Id is that (at the risk of stating the obvious) it identifies the vendor. Vendor A's applications are associated with it's Vendor Id, so Vendor B's devices only need to look at the Vendor Id to decide how to handle VSE's. I'm not saying it's better than your proposal, I'm just saying it's much the same and would require less work than your proposal since I believe this is what the intention of what was originally in Diameter was. > Since the experimental command code could exist in multiple applications, > the Vendor ID in the header does not provide uniqueness for the experimental > command code. > It doesn't need to. There is uniqueness though in the combination of Vendor Id and command code. If a vendor wants to reuse a command code under it's own vendor id, then that is the vendor's problem since only it's devices would be affected because all other vendor's devices can dismiss the applications on the basis of the vendor id. > Therefore, since the experimental command is tied to an application id, but > not to a vendor id, I see no way in which a vendor id would provide > any useful information for message routing. Evidently, from the above, I do. > > John ------_=_NextPart_001_01C22423.81BD489A Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Text needed for: Applicaiton ID in the = header

> Hi Dan,
>
>
> > Not trying to be argumentative but can = someone explain how this is better than;-
> > 1) Vendor ID is needed in the Diameter = header for efficient processing (servers
>      that don't = recognise the Vendor-Id dismiss the application/command).
> > 2) Vendor ID is ALREADY unique and = registered with IANA, and exists today
> > 3) Application does not need to be unique = and can be allocated by the vendor,
>      because of point = 1.
> > ... which I think is what we have now... =
>
> A single Vendor ID could be applicable for = multiple application IDs. A vendor
> might make multiple applications.  3GPP = has at least 2 applications,
> I think ...
>

If the device looks at the Vendor Id and doesn't = recognise it, then it can dismiss the application and commands without = further processing.  The point of having the Vendor Id is that (at = the risk of stating the obvious) it identifies the vendor.  Vendor = A's applications are associated with it's Vendor Id, so Vendor B's = devices only need to look at the Vendor Id to decide how to handle = VSE's.  I'm not saying it's better than your proposal, I'm just = saying it's much the same and would require less work than your = proposal since I believe this is what the intention of what was = originally in Diameter was.

> Since the experimental command code could exist = in multiple applications,
> the Vendor ID in the header does not provide = uniqueness for the experimental
> command code.
>
It doesn't need to.  There is uniqueness though = in the combination of Vendor Id and command code.  If a vendor = wants to reuse a command code under it's own vendor id, then that is = the vendor's problem since only it's devices would be affected because = all other vendor's devices can dismiss the applications on the basis of = the vendor id.

> Therefore, since the experimental command is = tied to an application id, but
> not to a vendor id, I see no way in which a = vendor id would provide
> any useful information for message = routing.

Evidently, from the above, I do.

>
> John

------_=_NextPart_001_01C22423.81BD489A-- From owner-aaa-wg@merit.edu Fri Jul 5 11:21:00 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29304 for ; Fri, 5 Jul 2002 11:20:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4CDBA91309; Fri, 5 Jul 2002 11:19:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11FC89130D; Fri, 5 Jul 2002 11:19:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44F7D91309 for ; Fri, 5 Jul 2002 11:19:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23B695DDD5; Fri, 5 Jul 2002 11:19:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 7E1B35DDA8 for ; Fri, 5 Jul 2002 11:19:48 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g65FLgW28664 for ; Fri, 5 Jul 2002 18:21:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Jul 2002 18:19:47 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 5 Jul 2002 18:20:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Text needed for: Applicaiton ID in the header Date: Fri, 5 Jul 2002 18:19:46 +0300 Message-ID: <9E3407CE45911B4097632389B77B2023107939@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIkI5a5BYqookwbR2OeIAnCjM3pUwACcxaQ From: To: Cc: X-OriginalArrivalTime: 05 Jul 2002 15:20:13.0040 (UTC) FILETIME=[75598F00:01C22437] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1) With or without Vendor-Id moving the Application-Id in the header helps the routing. 2) It seems to me that IESG position in the VSC discussion is consistent with its history. An analogy with TCP and UDP ports could help: one can play/experiment with any of the non-reserved ports and this doesn't create much trouble, but if a vendor wants to reserve a port for its wonderful application, then it must register it. Imposing the Vendor-Id would make it difficult (maybe even from legal point of view) for a lot of organizations that are not registered with IANA to play/experiment with Diameter. I read the interoperability problem raised by IESG more like an equal chances problem. 3) Removing the Vendor-Id from the header and letting it in the AVP header is not a consistent solution. But if you remove it from the AVP header you must either forbid non-standard AVPs in the standard commands (thus dropping one of the ways of extending the base protocol, but avoiding the complications) or replace it with something else. Adrian -----Original Message----- From: ext Daniel Warren [mailto:dlwarren@nortelnetworks.com] Sent: 05 July, 2002 15:57 To: Loughney John (NRC/Helsinki); gwz@cisco.com; Constantin Adrian (NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header > Hi Dan, > > > > Not trying to be argumentative but can someone explain how this is better than;- > > 1) Vendor ID is needed in the Diameter header for efficient processing (servers > that don't recognise the Vendor-Id dismiss the application/command). > > 2) Vendor ID is ALREADY unique and registered with IANA, and exists today > > 3) Application does not need to be unique and can be allocated by the vendor, > because of point 1. > > ... which I think is what we have now... > > A single Vendor ID could be applicable for multiple application IDs. A vendor > might make multiple applications. 3GPP has at least 2 applications, > I think ... > If the device looks at the Vendor Id and doesn't recognise it, then it can dismiss the application and commands without further processing. The point of having the Vendor Id is that (at the risk of stating the obvious) it identifies the vendor. Vendor A's applications are associated with it's Vendor Id, so Vendor B's devices only need to look at the Vendor Id to decide how to handle VSE's. I'm not saying it's better than your proposal, I'm just saying it's much the same and would require less work than your proposal since I believe this is what the intention of what was originally in Diameter was. > Since the experimental command code could exist in multiple applications, > the Vendor ID in the header does not provide uniqueness for the experimental > command code. > It doesn't need to. There is uniqueness though in the combination of Vendor Id and command code. If a vendor wants to reuse a command code under it's own vendor id, then that is the vendor's problem since only it's devices would be affected because all other vendor's devices can dismiss the applications on the basis of the vendor id. > Therefore, since the experimental command is tied to an application id, but > not to a vendor id, I see no way in which a vendor id would provide > any useful information for message routing. Evidently, from the above, I do. > > John From owner-aaa-wg@merit.edu Fri Jul 5 15:58: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 PAA14395 for ; Fri, 5 Jul 2002 15:58:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 364B89124E; Fri, 5 Jul 2002 15:59:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05EBC9124F; Fri, 5 Jul 2002 15:59:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E80179124E for ; Fri, 5 Jul 2002 15:59:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCBCE5DDEF; Fri, 5 Jul 2002 15:59:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 342615DDCA for ; Fri, 5 Jul 2002 15:59:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g65J7GP06757 for ; Fri, 5 Jul 2002 12:07:16 -0700 Date: Fri, 5 Jul 2002 12:07:16 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: types of experimental command In-Reply-To: <9E3407CE45911B4097632389B77B2023107939@esebe014.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > 3) Removing the Vendor-Id from the header and letting it in the AVP header is not > a consistent solution. But if you remove it from the AVP header you must > either forbid non-standard AVPs in the standard commands (thus dropping > one of the ways of extending the base protocol, but avoiding the > complications) or replace it with something else. Vendor-specific AVPs and Vendor-Specific commands are separable issues. Since there has been no IESG objection to vendor-specific AVPs, and since these have a long history (they are supported in RADIUS), and there is WG consensus on keeping vendor-specific AVPs, we should assume that support for vendor-specific AVPs will remain in Diameter, and we don't need to revisit the issue. Similarly, I don't believe that it makes sense to forbid VSAs within standard commands. This is also something that has been supported in RADIUS for a long time, and so I'd like to take that issue off the table as well. One thing that I do think is relevant is to have an explicit discussion of the nature of the Diameter dictionary versus the RADIUS dictionary. The RADIUS dictionary is assumed to enable definition of new AVPs, vendor-specific or standard on a RADIUS server, as long as they correspond to known types. There is typically no concept of a dictionary on the NAS though, since while a RADIUS server can easily define a new AVP via a dictionary addition, the NAS typically needs new code to be added to support carrying out the function described by the new AVP. Diameter has a similar dictionary capability, but it is more flexible, since there are more attribute types, as well as support for grouped AVPs. Also, Diameter dictionaries, while not standardized, can typically deal with command extensions as well as AVP extensions, and can define the required syntax via the ABNF. For example, it is possible to define a new application and to make it clear what attributes are required and optional within that application, so that a Diameter server can judge whether an incoming command is syntactically correct, without necessarily requiring any new code. In principle, this might allow Diameter to more gracefully handle new network access methods, particularly where some attributes required or optional in a conventional command do not make sense. For example, in xDSL provisioning, concepts from multi-link ISDN (e.g. Port-Limit) don't make sense. In RADIUS, there is no way to express a grammar where when NAS-Port-Type=16 (xDSL), a Port-Limit attribute is not permitted. The Diameter ABNF can do this. Ideally, it would be nice to be able to add support for xDSL access to Diameter without having to change a line of code within the Diameter server. The Diameter dictionary and ABNF get us most of the way there, because it should be possible to define the new command and ABNF describing what the command can contain. The problem comes in interpretting the meaning of the command. A new command could be essentially the same as a standard command with a slightly different ABNF for a new access type; or it could imply dramatically different functionality. In the latter case, a code change is required on *both* the NAS and Diameter Server in order to support it. In the former case, only the NAS requires a code change. Thus, it seems to me that it would be valuable to define the two types of experimental command: 1) One type of "experimental" command which implies "this command is essentially the same as an existing standard command, but with a new ABNF", and perhaps some new (or vendor-specific AVPs). With such a command, the Diameter server can look for the ABNF corresponding to the command code and know what to do with no code changes. The NAS will typically need a code change though. 2) Another type of "experimental" command which implies "this command is a new animal, and if you don't understand it, send an error message." This kind of command requires new code on both the Diameter server and NAS. Does this make sense? From owner-aaa-wg@merit.edu Sat Jul 6 16:05: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 QAA29562 for ; Sat, 6 Jul 2002 16:05:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB48D91263; Sat, 6 Jul 2002 16:06:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A9A791264; Sat, 6 Jul 2002 16:06:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DD2191263 for ; Sat, 6 Jul 2002 16:06:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3A145DDC7; Sat, 6 Jul 2002 16:06:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8F8745DDAB for ; Sat, 6 Jul 2002 16:06:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g66JE8p21396; Sat, 6 Jul 2002 12:14:08 -0700 Date: Sat, 6 Jul 2002 12:14:08 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: Nenad Trifunovic , AAA WG Subject: Re: [AAA-WG]: RE: Issue w/issue 308 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The issue is that the values in issue 308 don't match the ANSI values; so > the question is, will the issue be resolved in your opinion if only the ANSI > values are used in our document? Also, although you registered the RADIUS > attribute before RFC 2865 was published, it might be a nice idea to publish > an RFC describing it (as is required by the IANA considerations section of > RFC 2865. I assume that this will happen once we've got the text for the Diameter AVP. From owner-aaa-wg@merit.edu Mon Jul 8 02:03: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 CAA29469 for ; Mon, 8 Jul 2002 02:03:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8333B91266; Mon, 8 Jul 2002 02:03:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8865A91267; Mon, 8 Jul 2002 02:02:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CDB891266 for ; Mon, 8 Jul 2002 02:02:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 731005DF8A; Mon, 8 Jul 2002 02:02:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CAB555DF7A for ; Mon, 8 Jul 2002 02:02:04 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6862Xi17513 for ; Mon, 8 Jul 2002 09:02:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 09:02:03 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 09:02:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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]: Text needed for: Applicaiton ID in the header Date: Mon, 8 Jul 2002 09:02:02 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EAA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text needed for: Applicaiton ID in the header Thread-Index: AcIkI5czQvEigCw8TXOOZlX2Av3HzQCIJmgQ From: To: , , Cc: X-OriginalArrivalTime: 08 Jul 2002 06:02:03.0593 (UTC) FILETIME=[FB52BB90:01C22644] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dan, > If the device looks at the Vendor Id and doesn't recognise it, then it can > dismiss the application and commands without further processing. The > point of having the Vendor Id is that (at the risk of stating the obvious) > it identifies the vendor. Vendor A's applications are associated with it's > Vendor Id, so Vendor B's devices only need to look at the Vendor Id to decide > how to handle VSE's. I'm not saying it's better than your proposal, I'm > just saying it's much the same and would require less work than your > proposal since I believe this is what the intention of what was originally > in Diameter was. Currently, there is no text for the above behavior in the draft. That is one problem. The other problem is what is the behavior for relays and proxies. Do wee need to add text to say that messages must be routed using vendor ids as well? THis would be a problem. An example scenario would be two operators who are using a vendor specific command. In between them, there is a relay, who knows nothing of this command. If the relay would drop all messages containing the vendor id, then there communication between the two operators would broken. Currently, diameter message routing is done on application id, as a secondary key. By moving the application id into the header, message processing is simpler. One problem, though is, if the vendor-id + application id uniquely define an application, then we need to route on one more field, the vendor id. John From owner-aaa-wg@merit.edu Mon Jul 8 03:51: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 DAA07087 for ; Mon, 8 Jul 2002 03:51:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43CF691239; Mon, 8 Jul 2002 03:52:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E94C89126A; Mon, 8 Jul 2002 03:52:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB1A691239 for ; Mon, 8 Jul 2002 03:52:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B8DDD5DF77; Mon, 8 Jul 2002 03:52:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 0CE725DDCB for ; Mon, 8 Jul 2002 03:52:00 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g687rvW28078 for ; Mon, 8 Jul 2002 10:53:57 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Jul 2002 10:51:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 10:51:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: types of experimental command Date: Mon, 8 Jul 2002 10:51:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EAC@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: types of experimental command Thread-Index: AcIkXnn5xUMhiwCkRlyXB/3Gy/WDigB9K66w From: To: , X-OriginalArrivalTime: 08 Jul 2002 07:51:58.0991 (UTC) FILETIME=[567C99F0:01C22654] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA07087 Hi Bernard, > Vendor-specific AVPs and Vendor-Specific commands are > separable issues. > > Since there has been no IESG objection to vendor-specific AVPs, and since > these have a long history (they are supported in RADIUS), and there is WG > consensus on keeping vendor-specific AVPs, we should assume that support > for vendor-specific AVPs will remain in Diameter, and we don't need to > revisit the issue. > > Similarly, I don't believe that it makes sense to forbid VSAs within > standard commands. This is also something that has been supported in > RADIUS for a long time, and so I'd like to take that issue > off the table as well. I agree. [text clipped] > The problem comes in interpretting the meaning of the command. A new > command could be essentially the same as a standard command with a > slightly different ABNF for a new access type; or it could imply > dramatically different functionality. In the latter case, a code change is > required on *both* the NAS and Diameter Server in order to support it. In > the former case, only the NAS requires a code change. > > Thus, it seems to me that it would be valuable to define the > two types of experimental command: > > 1) One type of "experimental" command which implies "this > command is essentially the same as an existing standard command, but with > a new ABNF", and perhaps some new (or vendor-specific AVPs). > With such a command, the Diameter server can look for the ABNF > corresponding to the command code and know what to do with no code changes. > The NAS will typically need a code change though. > > 2) Another type of "experimental" command which implies "this command is a > new animal, and if you don't understand it, send an error message." This > kind of command requires new code on both the Diameter server and NAS. > > Does this make sense? The issue I would have with this, is can we make a clear division between the two. At what point does a experimental command, which is based upon an existing command become a new animial? One thing we could do is to suggest that experimental commands that are based on existing commands, include the command code in its ABNF. This would give a clue to server on how to process the command. Would this be reasonable? John From owner-aaa-wg@merit.edu Mon Jul 8 18:44: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 SAA15181 for ; Mon, 8 Jul 2002 18:44:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC4A891284; Mon, 8 Jul 2002 18:44:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DCFC91285; Mon, 8 Jul 2002 18:44:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61BD591284 for ; Mon, 8 Jul 2002 18:44:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45D755DE69; Mon, 8 Jul 2002 18:44:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id E6BE85DD8C for ; Mon, 8 Jul 2002 18:44:56 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g68MiZP07611; Mon, 8 Jul 2002 18:44:35 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA21690; Mon, 8 Jul 2002 17:44:35 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GYYCIA-0001EO-00; Mon, 08 Jul 2002 18:44:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15658.5584.509072.785400@gargle.gargle.HOWL> Date: Mon, 8 Jul 2002 17:44:32 -0500 From: Pete McCann To: Cc: , , Subject: [AAA-WG]: Diameter Base: Application ID proposal In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65610@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65610@esebe004.NOE.Nokia.com> X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > Hi all, > > Reviewing the current spec, I think it is important to make > the Application ID unique, across IETF standards and > Vendor Applications. What this means is that there would > be an IANA registry which would work on a first come, first > serve basis. In the IANA registry, there would be a field > to state the vendor and contact person. In the case of an > IETF standard application, this would reduce down to IETF & > the RFC number. Does this sound reasonable? > This would be aid message routing greatly. > > Comments? I think this approach makes sense. I am a bit confused about the current status of the discussions - I read draft-12 and I see the Vendor-ID is there in the header. Is the current consensus to keep it there or remove it? With the above, I guess it doesn't really need to be there, although it could be an aid to certain implementations. Also, will the experimental assignments for application IDs be permanent or temporary? John, I liked the text you proposed in email on 6/30 but which I don't see in the current draft-12. It allocated 24 bits worth of vendor-specific application IDs, which should easily be large enough. I would hope that we can make the assignments permanent, but if even the existence of this space is only temporary in order to satisfy the IESG concerns, then we essentially have an expiration date for all of 3GPP's specification work. It sounds like some people want that (scenario 4 from Jari's mail), but is that really what we are headed for? I think a lot of the text in draft-12 is still a bit schizophrenic with respect to "vendor-specific" vs. "experimental." Do we now have both "Experimental Applications" and within those, "Experimental Commands?" Are these equivalent to the terms "Vendor-Specific Application" and "Vendor-Specific Command"? The text I supplied for section 3 may need to be changed, as I don't think the AVP needs to be parsed anymore just to dispatch the command: Command-Code values in the range 0xfffff0 through 0xffffff are reserved for experimental use. Commands in this range MUST include a Vendor-Specific Application ID (see section 6.11) as the first AVP. The Vendor-Specific Application ID, together with the Command-Code value, determines the meaning of the experimental command. Change to: Command-Code values in the range 0xfffff0 through 0xffffff are reserved for experimental use. Commands in this range MUST use an IANA-assigned Application ID from the range 0xff00000000 - 0xfffffffe (see Section 11.3). Commands in this range MUST also include a Vendor-Specific Application ID AVP (see section 6.11). This is assuming that your e-mail text for Section 11.3 is adopted. Finally, I wonder if the following is really what we want: Experimental Command Codes, where the Vendor-Id field in the Diameter header is set to a non-zero value, are for private, experimental usage. These codes are only for experimental purposes, no guarentee is made for interoperability between Diameter peers using experimental commands. The range of values will have a limited lifetime, and will eventually be reconsumed into the range available for standardization. I personally think that the experimental command range is useful to keep around for the forseeable future, in case vendors or groups other than 3GPP want to carry out Diameter experiments. So, I would strike the last sentence from the above. We still would have the "control" of the Application ID assignment, which could be temporary if desired. This could even be determined on a case-by-case basis, depending on the deployment of a particular application and its timeline for standardization in the IETF. However, I can't imagine documenting a particular policy for how to set this lifetime and the whole idea of temporary assignments seems like a quagmire that we should avoid. -Pete From owner-aaa-wg@merit.edu Tue Jul 9 06:09: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 GAA18260 for ; Tue, 9 Jul 2002 06:09:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0B8E91298; Tue, 9 Jul 2002 06:09:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 823D791299; Tue, 9 Jul 2002 06:09:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 662E391298 for ; Tue, 9 Jul 2002 06:09:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 484C75DE72; Tue, 9 Jul 2002 06:09:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id A0C5A5DDA9 for ; Tue, 9 Jul 2002 06:09:40 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g69ABbW19660 for ; Tue, 9 Jul 2002 13:11:37 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Jul 2002 13:09:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 13:09:37 +0300 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Diameter Base: Application ID proposal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Jul 2002 13:09:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656A7@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter Base: Application ID proposal Thread-Index: AcIm0RGEMHz8l+RHQwipymksQX7yZgAX32iw From: To: Cc: , , X-OriginalArrivalTime: 09 Jul 2002 10:09:37.0252 (UTC) FILETIME=[BB34FA40:01C22730] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA18260 Hi Pete, > I am a bit confused about the current status of the discussions - I > read draft-12 and I see the Vendor-ID is there in the header. Is the > current consensus to keep it there or remove it? With the above, I > guess it doesn't really need to be there, although it could be an aid > to certain implementations. Version 12 was not submitted, it is for discussion. I think that current consensus seems to indicate that we remove it. I will be updating the spec by the end of the week. John From owner-aaa-wg@merit.edu Fri Jul 12 03:58: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 DAA10719 for ; Fri, 12 Jul 2002 03:58:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E23519139A; Fri, 12 Jul 2002 03:59:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF06A9139B; Fri, 12 Jul 2002 03:59:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B820E9139A for ; Fri, 12 Jul 2002 03:59:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98F1C5DE06; Fri, 12 Jul 2002 03:59:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3DD515DDB3 for ; Fri, 12 Jul 2002 03:59:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6C76r812654 for ; Fri, 12 Jul 2002 00:06:53 -0700 Date: Fri, 12 Jul 2002 00:06:52 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 10 Jul 2002 09:07:58 -0400 From: Luis A. Sanchez To: Bernard Aboba , Randy Bush , "Wijnen, Bert (Bert)" Subject: Re: FW: request for review from AAA WG Bernard, Enclosed you will find a review of the Diameter Mobile IPv4 application. There is more to review here including the CMS interactions . I have to finish a MIPv6 review first and then get back to CMS. This won't happen until after the IETF meeting. My apologies for the delay. Regards, Luis ================================= General Comments ---------------- - The document uses terminology used in other standards documents. For example, in the IPsec context, security associations are simplex and uniquely identified by the triple (IP address, SPI, protocol). It is not clear if there is a 1 to 1 mapping between IPsec security associations and the "security associations" between mobile nodes and AAA servers. - There is no explanation on the KDC functionality with message exchanges in the introduction section. This would help understand the feature. - The KDC part of the protocol is not symmetric. It sends keying material to the MN and sessions keys to the FA. It is not clear why this is the case. - The security considerations sections does not provide any considerations about the KDC feature of the protocol. Specific Comments ----------------- Section 1.0 1) Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Problem: Confusing sentence, what protocol? Suggestion: "... capability of the Diameter base protocol... 2) Strong authentication and confidentiality of session keys is required, and it is recommended to be provided using the CMS security application [CMS], but may be provided via other security mechanisms, e.g. using mutually authenticated TLS or IPsec when deployed in an environment without Diameter agents, then hop-by-hop security is sufficient for protecting session keys. Problem: Missing a comma or period after "IPsec". Otherwise it reads as a recommendation to use IPsec only when Diameter agents are *NOT* present. Suggestion: "... but may be provided via other security mechanisms, e.g. using mutually authenticated TLS or IPsec, when deployed in an environment without Diameter agents, then hop-by-hop security is sufficient for protecting session keys." Section 1.2 1) "This means that without support of the AAA NAI extension, the FA may not be able to guarantee, that the AMR well be destined to the same AAAH, which previously authenticated and authorized the mobile node, since the FA may not know the identity of the AAAH." Problem: extra word (well) found in sentence fragment. Suggestion: Please delete "well" in front of "be destined" 2) "Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer (AMA) message, includes the Acct-Multi-Session-Id that was present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs in the AMA message, enabling appropriate firewall controls for the penetration of tunneled traffic between the home agent and the mobile node." Problem: The authors mention firewall controls and there is no clear understanding on what exactly does it mean in this context. For example, does it means that one of the AVPs will include packet filtering rules that MUST be implemented in some firewall? If so, what are the selectors fields for these rules, what entity will push these rules to the firewall and how one validate the authenticity of the rules. One may also want to provide confidentiality to such rules. The latter can piggyback on the existing secured exchanged but it needs some clarification. As you can see this opens a can of worms. Suggestion: Please clarify what is meant by "firewall controls" and establish the exact operation and security model (if needed). If meant something different please clarify too. Section 1.4 1) If no security association exists between the AAAH and the originating AAAF, the AAAH will make use of the CMS application [CMS] to establish this association. Problem: This statement seems to imply that the only mechanism that can be used to establish a security association is CMS which contradicts previously made statements. Suggestion: Modify statement to include other mechanisms such as IPsec. 2) Figure 6: Mobile IP/Diameter Message Exchange Problem: Same figure caption as in figure 2. Suggestion: Change caption to indicated that it is "Figure 6: Mobile IP/Diameter Message Exchange when HA is in Visited Realm" or something similar. 3) If the mobile node is allowed to keep the home agent the AAAH then sends a HAR, which contains the Mobile IP Registration Request message data encapsulated in the MIP-Reg-Request AVP and the MIP- Home-Agent-Address AVP with home agent address, as well as any optional KDC session keys, to the AAAF in foreign network 1. Problem: First time KDC is mentioned and no further explanation is given. Suggestion: Introduce the entire KDC feature first. Architecture view should suffice. Need to explain the security for each message exchange. Section 1.6 1) Diameter Session Termination Problem: When an STR is sent what happens to the session keys? Suggestions: All resources (including session keys) must be deallocated (destroy) at the AAAH. Section 5.1 1) A value of zero indicates infinity (no time-out). Problem: This setting is of high security risk. However useful for debugging purposes. Suggestion: Please make a note in the document indicating that this setting is not recommended since keeping session keys for a long time (no refresh) increases the vulnerability of the system. Section 5.2 1) The key sent to the mobile node is always in the form of key material, which the AAAH does by generating a random [RANDOM] value of at least 64 bits. Problem: The KDC system is asymmetric. It sends keying material in one case (to the MN) and session keys in other cases (FA). Suggestion. Make the system symmetric. THe home AAAH server MUST generate all session keys and send them to the MN, FA and HA respectively. 2) The following is an example of a session creation procedure, using MD5 as the hashing algorithm. Additional algorithms are supported, and listed in [MIPKEYS]. MD5(AAA-Key | key material | node-address | AAA-Key) Problem: For key derivation, this document recommends using MD5/prefix+suffix mode. Back in 1996 Bellare, Canetti and Krawczyk published a paper on crypto discussing how a keyed hash function used in append/pre-append mode is more susceptible to the "divide and conquer" attack, although impractical, than a keyed-hashed function using a keyed-IV instead. They also proved that cryptographic ally HMAC is as strong as the hash function used with it. One can no make such a statement with a key-hashed function used in prefix+suffix mode. As such, IPsec dropped RFC1828 and adopted HMAC-MD5 and HMAC-SHA1 the latter truncated to 90bits. Another potential problem with MD5/prefix+suffix could come in if the nonsecret component of the key is variable length. In that case, if you were using MD5(secret, nonsecret) = newkey, then someone might be able to see newkey and later observe an exchange where nonsecret' = nonsecret|1. Then the key would be MD5(newkey, 1) = newkey'. You have to analyze the protocol very carefully to assure that this doesn't happen, but if you use HMAC, you don't have to worry about it. **Recommendation: Advise reader to derive keys using: key = HMAC-MD5(AAA-key, {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using MD5/prefix+suffix. 3) "- AAA-Key is the long term secret shared between the mobile node and the AAAH." Problem: The AAA key need to be chosen at random (or using a cryptographically strong pseudo-random generator seeded with a random seed), and periodically refreshed. It is not clear that we can recommended a specific frequency for key changes as the attacks refer to above may seem practically unfeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key. **Recommendation: Add a statement to ensure that both the Mobile Node and the AAA server refresh their shared AAA-key. THis could be done via the AAA protocol or some other out-of-band mechanism. For in-band refreshing the new key MUST be encrypted, authenticated and its integrity MUST be protected while on transit. 4) "The Foreign-Home session key is shared between two mobility agents: the FA and HA. Since this key is not destined for the mobile node, there is no need to follow the session key generation procedures detailed above. Instead, the AAAH generates a random [RANDOM] value of at least 64 bits for use as the Foreign-Home session key." Problem: This text seems to suggest that the security level required between the FA and HA is lower hence no need to create/use a cryptographically generated session key. What is the argument for this? Suggestion: Please explain. A symmetric protocol is easier to analyze and understand its security. Section 5.5.2 1) If the session key needs to be encrypted, the AAAF will check if a security association can be established, using the CMS security application [CMS] with the originating host found in the MIP- Originating-Foreign-AAA AVP. Problem: Sessions keys MUST always be encrypted. This function seems to be attached to CMS and this should not be the case. SUggestion: Always encrypt the session key using permanent keys (AAA-keys) Section 6.0 1) In other words, AAA servers MUST be able to create three session keys: the Mobile-Home, Mobile-Foreign, and Foreign-Home keys. Problem: Inconsistent with previous statements. The message sent to the MN does not contain a session key but rather the keying material. Suggestion: Eliminate this problem by having the AAAH calculate all keys except in the case where the HA is in the foreign realm in which case the AAAF will calculate the session key for the HA. Section 6.8 MIP-Algorithm-Type AVP 1) The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and contains the Algorithm identifier used to generate the associated Mobile IP authentication extension. The following values are currently defined: 1 Prefix+Suffix MD5 [MOBILEIP] 2 HMAC-MD5 [HMAC] 3 HMAC-SHA-1 [HMAC] Problem: as explained before. Suggestion: deprecate option 1 From owner-aaa-wg@merit.edu Fri Jul 12 06:41: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 GAA15900 for ; Fri, 12 Jul 2002 06:41:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F35329139E; Fri, 12 Jul 2002 06:41:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA15B9139F; Fri, 12 Jul 2002 06:41:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C78139139E for ; Fri, 12 Jul 2002 06:41:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC2435DE78; Fri, 12 Jul 2002 06:41:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by segue.merit.edu (Postfix) with ESMTP id 60D8A5DDB3 for ; Fri, 12 Jul 2002 06:41:41 -0400 (EDT) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id LAA27665; Fri, 12 Jul 2002 11:41:39 +0100 (BST) From: Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard1 (4.6.1.91) with ESMTP id for ; Fri, 12 Jul 2002 11:42:24 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 12 Jul 2002 11:41:51 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id <3GHX8C4S>; Fri, 12 Jul 2002 11:39:12 +0100 Message-Id: <671F9BA1F495D4118E8000A0C9E5CA4A038B6CF4@HIGHGATE> To: aaa-wg@merit.edu Subject: [AAA-WG]: Minor editorial in Base draft v.11 Date: Fri, 12 Jul 2002 11:41:48 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Just going through version 11 of the base draft and have found a very minor editorial. Submitter name: Nick Russell Submitter email address: Nick.Russell@vodafone.co.uk Date first submitted: 12 July 2002 Reference: Document: base Comment type: E Priority: 1 Section: 2 Rationale/Explanation of issue: In section 2 it is stated the following: "The base Diameter protocol is never used on its own. It is always extended for a particular application. Three Diameter applications are defined by companion documents: NASREQ [NASREQ], Mobile IP [DIAMMIP]. Unless I'm mistaken, there are only *two* Diameter applications listed; NASREQ and MIP. I believe this is left over from when CMS was removed...? Requested change: Change the word "Three" at the beginning of the second sentence to "Two". From owner-aaa-wg@merit.edu Fri Jul 12 08:07:19 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 IAA18562 for ; Fri, 12 Jul 2002 08:07:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 81703913A0; Fri, 12 Jul 2002 08:07:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46235913A1; Fri, 12 Jul 2002 08:07:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30CA3913A0 for ; Fri, 12 Jul 2002 08:07:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B22F5DED6; Fri, 12 Jul 2002 08:07:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id D2A685DEDF for ; Fri, 12 Jul 2002 08:07:55 -0400 (EDT) Received: from fmorn1dcode948i (a3.local.ipunplugged.com [192.168.4.173]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g6CC7TUg019294; Fri, 12 Jul 2002 14:07:29 +0200 From: "Fredrik Johansson" To: "Bernard Aboba" , Subject: RE: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (fwd) Date: Fri, 12 Jul 2002 14:08:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please see comments below. /Fredrik > > > ---------- Forwarded message ---------- > Date: Wed, 10 Jul 2002 09:07:58 -0400 > From: Luis A. Sanchez > To: Bernard Aboba , Randy Bush , > "Wijnen, Bert (Bert)" > Subject: Re: FW: request for review from AAA WG > > Bernard, > > Enclosed you will find a review of the > Diameter Mobile IPv4 > application. There is more to review here including the CMS interactions > . I have to finish a MIPv6 review first and then get back to CMS. This > won't happen until after the IETF meeting. My apologies for the delay. > > Regards, > > > Luis > > ================================= > > General Comments > ---------------- > > - The document uses terminology used in other standards documents. For > example, in the IPsec context, security associations are simplex and > uniquely identified by the triple (IP address, SPI, protocol). It is not > clear if there is a 1 to 1 mapping between IPsec security associations > and the "security associations" between mobile nodes and AAA servers. > > - There is no explanation on the KDC functionality with message > exchanges in the introduction section. This would help understand the > feature. > > - The KDC part of the protocol is not symmetric. It sends keying > material to the MN and sessions keys to the FA. It is not clear why this > is the case. This is done because otherwise we would need strong encryption of the keys sent to the MN. > > - The security considerations sections does not provide any > considerations about the KDC feature of the protocol. Perhaps the security consideration sections should say something on how to chose the MN-AAA key since that key is used when creating the session keys. > > > Specific Comments > ----------------- > > Section 1.0 > > 1) Combined with the Inter-Realm capability of the base protocol, this > application allows mobile nodes to receive service from foreign > service providers. > > Problem: Confusing sentence, what protocol? > Suggestion: "... capability of the Diameter base protocol... > > 2) Strong authentication and confidentiality of session keys is > required, and it is recommended to be provided using the CMS security > application [CMS], but may be provided via other security mechanisms, > e.g. using mutually authenticated TLS or IPsec when deployed in an > environment without Diameter agents, then hop-by-hop security is > sufficient for protecting session keys. > > Problem: Missing a comma or period after "IPsec". Otherwise it reads as > a recommendation to use IPsec only when Diameter agents are *NOT* present. > Suggestion: "... but may be provided via other security mechanisms, > e.g. using mutually authenticated TLS or IPsec, when deployed in an > environment without Diameter agents, then hop-by-hop security is > sufficient for protecting session keys." > > Section 1.2 > > 1) "This means that > without support of the AAA NAI extension, the FA may not be able to > guarantee, that the AMR well be destined to the same AAAH, which > previously authenticated and authorized the mobile node, since the FA > may not know the identity of the AAAH." > > Problem: extra word (well) found in sentence fragment. > Suggestion: Please delete "well" in front of "be destined" > > 2) "Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer > (AMA) message, includes the Acct-Multi-Session-Id that was present in > the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs > in the AMA message, enabling appropriate firewall controls for the > penetration of tunneled traffic between the home agent and the mobile > node." > > Problem: The authors mention firewall controls and there is no clear > understanding on what exactly does it mean in this context. For example, > does it means that one of the AVPs will include packet filtering rules > that MUST be implemented in some firewall? If so, what are the selectors > fields for these rules, what entity will push these rules to the > firewall and how one validate the authenticity of the rules. One may > also want to provide confidentiality to such rules. The latter can > piggyback on the existing secured exchanged but it needs some > clarification. As you can see this opens a can of worms. > > Suggestion: Please clarify what is meant by "firewall controls" and > establish the exact operation and security model (if needed). If meant > something different please clarify too. > > Section 1.4 > > 1) If no security association > exists between the AAAH and the originating AAAF, the AAAH will make > use of the CMS application [CMS] to establish this association. > > Problem: This statement seems to imply that the only mechanism that can > be used to establish a security association is CMS which contradicts > previously made statements. > > Suggestion: Modify statement to include other mechanisms such as IPsec. > > 2) Figure 6: Mobile IP/Diameter Message Exchange > > Problem: Same figure caption as in figure 2. > Suggestion: Change caption to indicated that it is "Figure 6: Mobile > IP/Diameter Message Exchange when HA is in Visited Realm" or something > similar. > > > 3) If the mobile node is allowed to keep the home agent the AAAH then > sends a HAR, which contains the Mobile IP Registration Request > message data encapsulated in the MIP-Reg-Request AVP and the MIP- > Home-Agent-Address AVP with home agent address, as well as any > optional KDC session keys, to the AAAF in foreign network 1. > > Problem: First time KDC is mentioned and no further explanation is given. > > Suggestion: Introduce the entire KDC feature first. Architecture view > should suffice. Need to explain the security for each message exchange. > > Section 1.6 > > 1) Diameter Session Termination > > Problem: When an STR is sent what happens to the session keys? > Suggestions: All resources (including session keys) must be deallocated > (destroy) at the AAAH. > > Section 5.1 > > > 1) A value of zero indicates infinity (no time-out). > > Problem: This setting is of high security risk. However useful for > debugging purposes. > > Suggestion: Please make a note in the document indicating that this > setting is not recommended since keeping session keys for a long time > (no refresh) increases the vulnerability of the system. > > Section 5.2 > > 1) The key sent to the mobile node is always in the form of key > material, which the AAAH does by generating a random [RANDOM] value > of at least 64 bits. > > Problem: The KDC system is asymmetric. It sends keying material in one > case (to the MN) and session keys in other cases (FA). > > Suggestion. Make the system symmetric. THe home AAAH server MUST > generate all session keys and send them to the MN, FA and HA respectively. The KDC generates all keys, but the only way to send the key to the MN without having to have strong encryption is to do it via key material. > > 2) The following is an example of a > session creation procedure, using MD5 as the hashing algorithm. > Additional algorithms are supported, and listed in [MIPKEYS]. > > MD5(AAA-Key | key material | node-address | AAA-Key) > > Problem: For key derivation, this document recommends using > MD5/prefix+suffix mode. Back in 1996 Bellare, Canetti and Krawczyk > published a paper on crypto discussing how a keyed hash function used in > append/pre-append mode is more susceptible to the "divide and conquer" > attack, although impractical, than a keyed-hashed function using a > keyed-IV instead. They also proved that cryptographic ally HMAC is as > strong as the hash function used with it. One can no make such a > statement with a key-hashed function used in prefix+suffix > mode. As such, IPsec dropped RFC1828 and adopted HMAC-MD5 and HMAC-SHA1 > the latter truncated to 90bits. Another potential problem with > MD5/prefix+suffix could come in if the nonsecret component of the key is > variable length. In that case, if you were using MD5(secret, nonsecret) > = newkey, then someone might be able to see newkey and later observe an > exchange where nonsecret' = nonsecret|1. Then the key would be > MD5(newkey, 1) = newkey'. You have to analyze the protocol very > carefully to assure that this doesn't happen, but if you use HMAC, you > don't have to worry about it. > > **Recommendation: Advise reader to derive keys using: key = > HMAC-MD5(AAA-key, > > {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using > MD5/prefix+suffix. Sounds reasonable, > > 3) "- AAA-Key is the long term secret shared between the mobile > node and the AAAH." > > Problem: The AAA key need to be chosen at random (or using a > cryptographically strong pseudo-random generator seeded with a random > seed), and periodically refreshed. It is not clear that we can > recommended a specific frequency for key changes as the attacks refer to > above may seem practically unfeasible. However, periodic key > refreshment is a fundamental security practice that helps against > potential weaknesses of the function and keys, and limits the damage of > an exposed key. > > **Recommendation: Add a statement to ensure that both the Mobile Node > and the AAA server refresh their shared AAA-key. THis could be done via > the AAA protocol or some other out-of-band mechanism. For in-band > refreshing the new key MUST be encrypted, authenticated and its > integrity MUST be protected while on transit. I suggest a section is added where we recomend the key to be refreshed but the means is outside the scope of this document. This key is typically somehting that you would get with the subscription or from your sysadmin and I believe that better to leave it to the different deployment scenarios to decide how and when to refresh this key. > > > 4) "The Foreign-Home session key is shared between two mobility agents: > the FA and HA. Since this key is not destined for the mobile node, > there is no need to follow the session key generation procedures > detailed above. Instead, the AAAH generates a random [RANDOM] value > of at least 64 bits for use as the Foreign-Home session key." > > Problem: This text seems to suggest that the security level required > between the FA and HA is lower hence no need to create/use a > cryptographically generated session key. What is the argument for this? Correct me if I'm wrong, but what difference does it make to the FA and HA if they get a random number to use as key between them or if they get a random number that has been hashed with some algorithm before sent to them, as long as the number is sent in a secure way. > > Suggestion: Please explain. A symmetric protocol is easier to analyze > and understand its security. > > Section 5.5.2 > > 1) If the session key needs to be encrypted, the AAAF will check if a > security association can be established, using the CMS security > application [CMS] with the originating host found in the MIP- > Originating-Foreign-AAA AVP. > > Problem: Sessions keys MUST always be encrypted. This function seems to > be attached to CMS and this should not be the case. I believe that the intention is that if the connection between say the AAAH and the HA is protected via IPSec, then there is no need to further encrypt the key since the whole communication is secured anyway, provided it's only one hop between them. I.e. it should not be mandatory to use CMS or some other end-to-end encryption mechanism in this case. > > SUggestion: Always encrypt the session key using permanent keys (AAA-keys) > > Section 6.0 > > 1) In other words, AAA > servers MUST be able to create three session keys: the Mobile-Home, > Mobile-Foreign, and Foreign-Home keys. > > Problem: Inconsistent with previous statements. The message sent to the > MN does not contain a session key but rather the keying material. > > Suggestion: Eliminate this problem by having the AAAH calculate all keys > except in the case where the HA is in the foreign realm in which case > the AAAF will calculate the session key for the HA. > > Section 6.8 MIP-Algorithm-Type AVP > > 1) The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and > contains the Algorithm identifier used to generate the associated > Mobile IP authentication extension. The following values are > currently defined: > > 1 Prefix+Suffix MD5 [MOBILEIP] > 2 HMAC-MD5 [HMAC] > 3 HMAC-SHA-1 [HMAC] > > Problem: as explained before. > Suggestion: deprecate option 1 Agree, make an example that suggest using 2 or 3. > > > > From owner-aaa-wg@merit.edu Fri Jul 12 08:22:28 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 IAA19058 for ; Fri, 12 Jul 2002 08:22:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07992913A1; Fri, 12 Jul 2002 08:23:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C068A913A2; Fri, 12 Jul 2002 08:23:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B749A913A1 for ; Fri, 12 Jul 2002 08:23:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8090B5DEE1; Fri, 12 Jul 2002 08:23:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id CC9B35DEE7 for ; Fri, 12 Jul 2002 08:23:06 -0400 (EDT) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g6CCMlUg019659; Fri, 12 Jul 2002 14:22:48 +0200 Message-ID: <3D2ECA08.3020002@ipunplugged.com> Date: Fri, 12 Jul 2002 14:22:32 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: Bernard Aboba Subject: Re: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik Johansson wrote: >>Section 5.5.2 >> >>1) If the session key needs to be encrypted, the AAAF will check if a >> security association can be established, using the CMS security >> application [CMS] with the originating host found in the MIP- >> Originating-Foreign-AAA AVP. >> >>Problem: Sessions keys MUST always be encrypted. This function seems to >>be attached to CMS and this should not be the case. >> >> > >I believe that the intention is that if the connection between say the AAAH >and the HA is protected via IPSec, then there is no need to further encrypt >the key since the whole communication is secured anyway, provided it's only >one hop between them. I.e. it should not be mandatory to use CMS or some >other end-to-end encryption mechanism in this case. > Obviously if the session keys are to be encrypted the AAAF and the Originating-Foreign-AAA must negotiate a key and a cryptoalgorithm somehow. Since these nodes will typically be located in different realms, or the OFAAA avp would probably not be needed, it seems infeasible to use preconfigured keys. How then will the negotiation take place once CMS is ruled out? It can't be implementation or even deployment specific since we are talking about several administrative domains. Wouldn't it by necessity have to be specified in the standard to make the standard work, since interoperability is what standards is all about and so on? >>SUggestion: Always encrypt the session key using permanent keys (AAA-keys) >> I can't see a way to do this in a scalable way. Hopefully someone else can. j From owner-aaa-wg@merit.edu Sat Jul 13 07:22: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 HAA20841 for ; Sat, 13 Jul 2002 07:22:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4120491263; Sat, 13 Jul 2002 07:23:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EC1491265; Sat, 13 Jul 2002 07:23:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93F8E91263 for ; Sat, 13 Jul 2002 07:23:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71F995DDF7; Sat, 13 Jul 2002 07:23:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C9F765DD9A for ; Sat, 13 Jul 2002 07:23:05 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6DBNZi17100 for ; Sat, 13 Jul 2002 14:23:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 13 Jul 2002 14:23:04 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 13 Jul 2002 14:23:04 +0300 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Minor editorial in Base draft v.11 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 13 Jul 2002 14:23:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01130804@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Minor editorial in Base draft v.11 Thread-Index: AcIpkMPG5PTGG6b7TUGuw2cfEg7PdAAI9xvA From: To: , X-OriginalArrivalTime: 13 Jul 2002 11:23:04.0421 (UTC) FILETIME=[A7BC9950:01C22A5F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20841 Hi Nick, Thanks for the issue, I'll fix it in ver 12. John > -----Original Message----- > From: ext [mailto:Nick.Russell@vf.vodafone.co.uk] > Sent: 12 July, 2002 13:42 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Minor editorial in Base draft v.11 > > > Just going through version 11 of the base draft and have > found a very minor > editorial. > > Submitter name: Nick Russell > Submitter email address: Nick.Russell@vodafone.co.uk > Date first submitted: 12 July 2002 > Reference: > Document: base > Comment type: E > Priority: 1 > Section: 2 > Rationale/Explanation of issue: > In section 2 it is stated the following: > > "The base Diameter protocol is never used on its own. It is always > extended for a particular application. Three Diameter applications > are defined by companion documents: NASREQ [NASREQ], Mobile IP > [DIAMMIP]. > > Unless I'm mistaken, there are only *two* Diameter > applications listed; > NASREQ and MIP. I believe this is left over from when CMS was > removed...? > > Requested change: > Change the word "Three" at the beginning of the second > sentence to "Two". > From owner-aaa-wg@merit.edu Thu Jul 25 08:04: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 IAA29674 for ; Thu, 25 Jul 2002 08:04:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3083A9130F; Thu, 25 Jul 2002 08:05:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01CFD91310; Thu, 25 Jul 2002 08:05:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC2109130F for ; Thu, 25 Jul 2002 08:05:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB1F35DE0E; Thu, 25 Jul 2002 08:05:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 1FE0D5DD93 for ; Thu, 25 Jul 2002 08:05:33 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6PC63i20265 for ; Thu, 25 Jul 2002 15:06:03 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 25 Jul 2002 15:05:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Jul 2002 15:05:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Diameter Base update Date: Thu, 25 Jul 2002 15:05:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657F0@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (fwd) Thread-Index: AcIpnu5vA+wX30mqSem0Au/hnvo65wKNGBWQ From: To: X-OriginalArrivalTime: 25 Jul 2002 12:05:31.0194 (UTC) FILETIME=[92B051A0:01C233D3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29674 Hi all, I have updated the base spec & sent it to the drafts editor for publication. For those of you who want to get an early look, it can be grabbed from here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt The major changes deal with the replacing of Vendor Command Codes with Experimental Command codes. Hopefully, the change is sufficient & we can send this to the IESG. John From owner-aaa-wg@merit.edu Thu Jul 25 20:43: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 UAA25691 for ; Thu, 25 Jul 2002 20:43:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52ED291203; Thu, 25 Jul 2002 20:43:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28F899121A; Thu, 25 Jul 2002 20:43:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 148DF91203 for ; Thu, 25 Jul 2002 20:43:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E62AE5DDD4; Thu, 25 Jul 2002 20:43:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 68AAD5DD92 for ; Thu, 25 Jul 2002 20:43:45 -0400 (EDT) Received: from GWZW2K (shinjuku-equant-dynamic16.cisco.com [64.104.42.16]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA15749; Thu, 25 Jul 2002 17:43:35 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Cc: Subject: RE: [AAA-WG]: Diameter Base update Date: Thu, 25 Jul 2002 17:43:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC657F0@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Loughney [mailto://john.loughney@nokia.com] writes: > Hi all, > > I have updated the base spec & sent it to the drafts editor > for publication. I think that this move is at best premature. Allison Mankin (the only IESG member I could find who had even partially read a recent version of the draft) has promised to produce a document 'in a couple of weeks' detailing her objections (if any) to the draft and I think it would be far better to wait and see what she has to say, instead of just caving in to Randy's technically unjustified demands. Furthermore, I find it difficult to believe that there is any WG consensus on these changes. > For those of you who want to get an > early look, it can be grabbed from here: > > http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt > > The major changes deal with the replacing of Vendor Command > Codes with Experimental Command codes. Hopefully, the > change is sufficient & we can send this to the IESG. I may be alone on this, but I don't believe that our job as a WG is to twist and spindle and mutilate our work until it is acceptable to the IESG (in this case, actually just one IESG member). Rather, our task is to produce the best work we can _through the rough-consensus based IETF process_ and submit it. If the IESG refuses to even look at it, then we should abandon our work, rather than participating in a clear violation of the process. Let _them_ explain to ITU-T and TIA (not to mention Vodafone, Orange, SK Telecom, etc.) why they are blocking the deployment of 3G, since they don't seem to be disposed to explain it to us. > > John > > From owner-aaa-wg@merit.edu Thu Jul 25 21:07: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 VAA26027 for ; Thu, 25 Jul 2002 21:07:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A6FDE91213; Thu, 25 Jul 2002 21:08:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CCB39121A; Thu, 25 Jul 2002 21:08:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 503FC91213 for ; Thu, 25 Jul 2002 21:08:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D9BA5DE72; Thu, 25 Jul 2002 21:08:06 -0400 (EDT) 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 15A395DD92 for ; Thu, 25 Jul 2002 21:08:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17XtaP-000IPd-00; Thu, 25 Jul 2002 18:08:05 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Glen Zorn" Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter Base update References: <0C1353ABB1DEB74DB067ADFF749C4EEFC657F0@esebe004.NOE.Nokia.com> Message-Id: Date: Thu, 25 Jul 2002 18:08:05 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit glen, i am having a hard time finding any technical substance in your argument. could you please be more clear? as 3gpp and all other actual users (including prominent cisco folk) have agreed that this is a sufficient forward path, the end of the world does not appear very nigh from this vantage point. and the ad homina are definitely not useful. randy >> I have updated the base spec & sent it to the drafts editor >> for publication. > > I think that this move is at best premature. Allison Mankin (the only IESG > member I could find who had even partially read a recent version of the > draft) has promised to produce a document 'in a couple of weeks' detailing > her objections (if any) to the draft and I think it would be far better to > wait and see what she has to say, instead of just caving in to Randy's > technically unjustified demands. Furthermore, I find it difficult to > believe that there is any WG consensus on these changes. > >> For those of you who want to get an >> early look, it can be grabbed from here: >> >> http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt >> >> The major changes deal with the replacing of Vendor Command >> Codes with Experimental Command codes. Hopefully, the >> change is sufficient & we can send this to the IESG. > > I may be alone on this, but I don't believe that our job as a WG is to twist > and spindle and mutilate our work until it is acceptable to the IESG (in > this case, actually just one IESG member). Rather, our task is to produce > the best work we can _through the rough-consensus based IETF process_ and > submit it. If the IESG refuses to even look at it, then we should abandon > our work, rather than participating in a clear violation of the process. > Let _them_ explain to ITU-T and TIA (not to mention Vodafone, Orange, SK > Telecom, etc.) why they are blocking the deployment of 3G, since they don't > seem to be disposed to explain it to us. From owner-aaa-wg@merit.edu Fri Jul 26 05:58:34 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 FAA12921 for ; Fri, 26 Jul 2002 05:58:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3AA569120F; Fri, 26 Jul 2002 05:59:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EA9391320; Fri, 26 Jul 2002 05:59:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA16B9120F for ; Fri, 26 Jul 2002 05:59:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BEAFD5DD95; Fri, 26 Jul 2002 05:59:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 253515DD92 for ; Fri, 26 Jul 2002 05:59:22 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020726095920.UHJJ710.fep02-svc.swip.net@ipunplugged.com>; Fri, 26 Jul 2002 11:59:20 +0200 Message-ID: <3D413A36.4030508@ipunplugged.com> Date: Fri, 26 Jul 2002 12:01:58 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush Cc: Glen Zorn , aaa-wg@merit.edu, mankin@isi.edu Subject: Re: [AAA-WG]: Diameter Base update References: <0C1353ABB1DEB74DB067ADFF749C4EEFC657F0@esebe004.NOE.Nokia.com> 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 As far as I know 3gpp had no problem with the original solution either. In fact, you are the only one who has ever *had* a problem with it, and you refuse to tell us what the problem is. Did you really ask "all other actual users"? Are you sure you didn't miss some? Also, I beg to differ that this is a sufficient forward path. Merging the command code namespaces is a backward path. Since this is to be an IETF standard it would seem more important that the workgroup agrees with the solution than anyone else. Glen's mail doesn't have technical substance since it's not about technical matters but about how to repair your blatant breach of IETF process, i.e. it does not express a technological argument but an administrative one. Even had it been lacking technical substance where such was merited, your first priority should be to explain your mysterious aversion to vendor specific commands and show why they are dangerous. This is and has been your task for the last month(s). John, you have submitted a draft that you know there is not only no workgroup consenus around, but rather there is workgroup opposition. Until Randy produces a solid case for his objections that will turn the workgroup's opinion in his favour, and note that I am still not excluding this possibility, the problem does not exist. If he refuses to pass the draft on without explaining in an acceptable way why he does so, we can always find another way to get it to the IESG. j Randy Bush wrote: >glen, > >i am having a hard time finding any technical substance in your >argument. could you please be more clear? > >as 3gpp and all other actual users (including prominent cisco folk) >have agreed that this is a sufficient forward path, the end of the >world does not appear very nigh from this vantage point. and the >ad homina are definitely not useful. > >randy > > > > >>>I have updated the base spec & sent it to the drafts editor >>>for publication. >>> >>> >>I think that this move is at best premature. Allison Mankin (the only IESG >>member I could find who had even partially read a recent version of the >>draft) has promised to produce a document 'in a couple of weeks' detailing >>her objections (if any) to the draft and I think it would be far better to >>wait and see what she has to say, instead of just caving in to Randy's >>technically unjustified demands. Furthermore, I find it difficult to >>believe that there is any WG consensus on these changes. >> >> >> >>>For those of you who want to get an >>>early look, it can be grabbed from here: >>> >>>http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt >>> >>>The major changes deal with the replacing of Vendor Command >>>Codes with Experimental Command codes. Hopefully, the >>>change is sufficient & we can send this to the IESG. >>> >>> >>I may be alone on this, but I don't believe that our job as a WG is to twist >>and spindle and mutilate our work until it is acceptable to the IESG (in >>this case, actually just one IESG member). Rather, our task is to produce >>the best work we can _through the rough-consensus based IETF process_ and >>submit it. If the IESG refuses to even look at it, then we should abandon >>our work, rather than participating in a clear violation of the process. >>Let _them_ explain to ITU-T and TIA (not to mention Vodafone, Orange, SK >>Telecom, etc.) why they are blocking the deployment of 3G, since they don't >>seem to be disposed to explain it to us. >> >> > > > From owner-aaa-wg@merit.edu Fri Jul 26 06:10:13 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 GAA13075 for ; Fri, 26 Jul 2002 06:10:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E4F6191320; Fri, 26 Jul 2002 06:11:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE15591323; Fri, 26 Jul 2002 06:11:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9860291320 for ; Fri, 26 Jul 2002 06:11:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 772315DE25; Fri, 26 Jul 2002 06:11:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by segue.merit.edu (Postfix) with ESMTP id 5921E5DD95 for ; Fri, 26 Jul 2002 06:11:01 -0400 (EDT) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id LAA01572; Fri, 26 Jul 2002 11:11:00 +0100 (BST) From: Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67]) by mailguard1 (4.6.1.91) with ESMTP id for ; Fri, 26 Jul 2002 11:11:42 +0100 Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 26 Jul 2002 11:11:07 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id <3GHYG6JP>; Fri, 26 Jul 2002 11:11:06 +0100 Message-Id: <671F9BA1F495D4118E8000A0C9E5CA4A038B6D6A@HIGHGATE> To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter Base update Date: Fri, 26 Jul 2002 11:11:00 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Randy et al, My interpretation of the agreement that was reached between 3GPP and the IETF AAA WG is that the experimental command codes are something 3GPP can *LIVE* with but it has its floors. Particularly if experimental command codes "limited lifetime" is only 2 years which I believe was the last agreement..? I would still prefer the original method of Vendor Command Codes with IANA assigning Vendor IDs which never expire. And I would be interested in reading a good technical argument as to why these limited lifetime Experimental Command Codes are better than the original Vendor Command Codes. As far as I can see, they're going to be worse as the lifetime from development, through testing, to full deployment/roll-out in a network such as ours, would be about 2 years! So by the time we've rolled it out, it's going to be prone to errors. How is this better!? Cheers, Nick P.S. Randy, I think you mean "ad hominem" or probably more specifically "argumentative ad hominem" which for those who don't know Latin, basically means attacking the man instead of the argument. > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: 26 July 2002 2:08am > To: Glen Zorn > Cc: aaa-wg@merit.edu; mankin@isi.edu > Subject: RE: [AAA-WG]: Diameter Base update > > > glen, > > i am having a hard time finding any technical substance in your > argument. could you please be more clear? > > as 3gpp and all other actual users (including prominent cisco folk) > have agreed that this is a sufficient forward path, the end of the > world does not appear very nigh from this vantage point. and the > ad homina are definitely not useful. > > randy > > > >> I have updated the base spec & sent it to the drafts editor > >> for publication. > > > > I think that this move is at best premature. Allison > Mankin (the only IESG > > member I could find who had even partially read a recent > version of the > > draft) has promised to produce a document 'in a couple of > weeks' detailing > > her objections (if any) to the draft and I think it would > be far better to > > wait and see what she has to say, instead of just caving in > to Randy's > > technically unjustified demands. Furthermore, I find it > difficult to > > believe that there is any WG consensus on these changes. > > > >> For those of you who want to get an > >> early look, it can be grabbed from here: > >> > >> http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt > >> > >> The major changes deal with the replacing of Vendor Command > >> Codes with Experimental Command codes. Hopefully, the > >> change is sufficient & we can send this to the IESG. > > > > I may be alone on this, but I don't believe that our job as > a WG is to twist > > and spindle and mutilate our work until it is acceptable to > the IESG (in > > this case, actually just one IESG member). Rather, our > task is to produce > > the best work we can _through the rough-consensus based > IETF process_ and > > submit it. If the IESG refuses to even look at it, then we > should abandon > > our work, rather than participating in a clear violation of > the process. > > Let _them_ explain to ITU-T and TIA (not to mention > Vodafone, Orange, SK > > Telecom, etc.) why they are blocking the deployment of 3G, > since they don't > > seem to be disposed to explain it to us. > From owner-aaa-wg@merit.edu Fri Jul 26 08:21:23 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 IAA16370 for ; Fri, 26 Jul 2002 08:21:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 702BE9132E; Fri, 26 Jul 2002 08:22:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4778C9132F; Fri, 26 Jul 2002 08:22:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2DBB19132E for ; Fri, 26 Jul 2002 08:22:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0EAD15DEFD; Fri, 26 Jul 2002 08:22:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 4AAA45DE8B for ; Fri, 26 Jul 2002 08:22:12 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6QCOKW10796 for ; Fri, 26 Jul 2002 15:24:20 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Jul 2002 15:22:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 15:22:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update Date: Fri, 26 Jul 2002 15:22:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC657FF@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter Base update Thread-Index: AcI0jVnH0TQzub42TUCMHkE/Bk2A4AAEKF4g From: To: , X-OriginalArrivalTime: 26 Jul 2002 12:22:06.0674 (UTC) FILETIME=[0E744320:01C2349F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA16370 Hi all, To prevent misunderstandings, VSCs were added in Diameter draft -03 (I think). Shortly after this, Randy Bush (wearing his AD hat) posted an issue about this. After the last WG last call, Randy said that as AD, he could not let the spec pass until this issue was resolved. The chairs, ADs, some IESG members and I had several calls to figure out ways to resolve this & verified that this was OK with 3GPP, via Stephen Hayes. The resolution of the issue is in the current draft, version 12. Now, I think that many members of the WG do not see the potential interoperability problem introduced by VSCs, and are asking for some illustrations on why this is a problem. I would hope that the WG Chairs & IESG members submit at least an example of how VSCs could get us into trouble. Finally, with regards to 3GPP. I understand that 3GPP has 2 unique uses of Diameter in their network. These uses should require seperate applications. Currently, the IETF is allowing the use of experimental command codes in these applications - I think only one actually requires them. 3GPP has intended to use vendor extensions for these cases, but I believe the IESG would prefer to see Internet Standards made from these applications. I think the next 3GPP release should use Internet Standards for these applications, which means some additional work for the AAA WG. After my vacation, I intend to review the existing drafts & see if I can assist these documents progress to RFC status. best regards, John > -----Original Message----- > From: ext [mailto:Nick.Russell@vf.vodafone.co.uk] > Sent: 26 July, 2002 13:11 > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter Base update > > > Randy et al, > > My interpretation of the agreement that was reached between 3GPP and the > IETF AAA WG is that the experimental command codes are something 3GPP can > *LIVE* with but it has its floors. Particularly if experimental command > codes "limited lifetime" is only 2 years which I believe was the last > agreement..? > > I would still prefer the original method of Vendor Command > Codes with IANA > assigning Vendor IDs which never expire. And I would be interested in > reading a good technical argument as to why these limited lifetime > Experimental Command Codes are better than the original Vendor Command > Codes. As far as I can see, they're going to be worse as the > lifetime from > development, through testing, to full deployment/roll-out in > a network such > as ours, would be about 2 years! So by the time we've rolled > it out, it's > going to be prone to errors. How is this better!? > > Cheers, > Nick > > P.S. > Randy, I think you mean "ad hominem" or probably more specifically > "argumentative ad hominem" which for those who don't know > Latin, basically > means attacking the man instead of the argument. > > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: 26 July 2002 2:08am > > To: Glen Zorn > > Cc: aaa-wg@merit.edu; mankin@isi.edu > > Subject: RE: [AAA-WG]: Diameter Base update > > > > > > glen, > > > > i am having a hard time finding any technical substance in your > > argument. could you please be more clear? > > > > as 3gpp and all other actual users (including prominent cisco folk) > > have agreed that this is a sufficient forward path, the end of the > > world does not appear very nigh from this vantage point. and the > > ad homina are definitely not useful. > > > > randy > > > > > > >> I have updated the base spec & sent it to the drafts editor > > >> for publication. > > > > > > I think that this move is at best premature. Allison > > Mankin (the only IESG > > > member I could find who had even partially read a recent > > version of the > > > draft) has promised to produce a document 'in a couple of > > weeks' detailing > > > her objections (if any) to the draft and I think it would > > be far better to > > > wait and see what she has to say, instead of just caving in > > to Randy's > > > technically unjustified demands. Furthermore, I find it > > difficult to > > > believe that there is any WG consensus on these changes. > > > > > >> For those of you who want to get an > > >> early look, it can be grabbed from here: > > >> > > >> http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt > > >> > > >> The major changes deal with the replacing of Vendor Command > > >> Codes with Experimental Command codes. Hopefully, the > > >> change is sufficient & we can send this to the IESG. > > > > > > I may be alone on this, but I don't believe that our job as > > a WG is to twist > > > and spindle and mutilate our work until it is acceptable to > > the IESG (in > > > this case, actually just one IESG member). Rather, our > > task is to produce > > > the best work we can _through the rough-consensus based > > IETF process_ and > > > submit it. If the IESG refuses to even look at it, then we > > should abandon > > > our work, rather than participating in a clear violation of > > the process. > > > Let _them_ explain to ITU-T and TIA (not to mention > > Vodafone, Orange, SK > > > Telecom, etc.) why they are blocking the deployment of 3G, > > since they don't > > > seem to be disposed to explain it to us. > > > From owner-aaa-wg@merit.edu Fri Jul 26 12:31:14 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28510 for ; Fri, 26 Jul 2002 12:31:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3B3591338; Fri, 26 Jul 2002 12:31:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C33B91339; Fri, 26 Jul 2002 12:31:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6288791338 for ; Fri, 26 Jul 2002 12:31:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FCC15DE16; Fri, 26 Jul 2002 12:31:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id DD1375DDAF for ; Fri, 26 Jul 2002 12:31:05 -0400 (EDT) Received: from GWZW2K (shinjuku-equant-dynamic124.cisco.com [64.104.42.124]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA09449; Fri, 26 Jul 2002 09:31:00 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Randy Bush" Cc: , Subject: RE: [AAA-WG]: Diameter Base update Date: Fri, 26 Jul 2002 09:30:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush [mailto:randy@psg.com] writes: > glen, > > i am having a hard time finding any technical substance in your > argument. could you please be more clear? There is no technical substance in my argument, it is simply a matter of process, and lack of WG consensus. > > as 3gpp and all other actual users (including prominent cisco folk) Perhaps some of those people would like to comment; I know that I have received several emails from 3GPP folk and others which were not happy in the least. > have agreed that this is a sufficient forward path, the end of the > world does not appear very nigh from this vantage point. and the > ad homina are definitely not useful. I hardly think that calling your argument "technically unjustified" qualifies as an ad hominem attack, nor does noting that the IESG members I spoke to hadn't read the draft (it's not even a dig: I wouldn't read it, either, unless I had to). > > randy > > > >> I have updated the base spec & sent it to the drafts editor > >> for publication. > > > > I think that this move is at best premature. Allison Mankin > (the only IESG > > member I could find who had even partially read a recent version of the > > draft) has promised to produce a document 'in a couple of > weeks' detailing > > her objections (if any) to the draft and I think it would be > far better to > > wait and see what she has to say, instead of just caving in to Randy's > > technically unjustified demands. Furthermore, I find it difficult to > > believe that there is any WG consensus on these changes. > > > >> For those of you who want to get an > >> early look, it can be grabbed from here: > >> > >> http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt > >> > >> The major changes deal with the replacing of Vendor Command > >> Codes with Experimental Command codes. Hopefully, the > >> change is sufficient & we can send this to the IESG. > > > > I may be alone on this, but I don't believe that our job as a > WG is to twist > > and spindle and mutilate our work until it is acceptable to the IESG (in > > this case, actually just one IESG member). Rather, our task is > to produce > > the best work we can _through the rough-consensus based IETF > process_ and > > submit it. If the IESG refuses to even look at it, then we > should abandon > > our work, rather than participating in a clear violation of the process. > > Let _them_ explain to ITU-T and TIA (not to mention Vodafone, Orange, SK > > Telecom, etc.) why they are blocking the deployment of 3G, > since they don't > > seem to be disposed to explain it to us. > > > From owner-aaa-wg@merit.edu Fri Jul 26 13:43: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 NAA01714 for ; Fri, 26 Jul 2002 13:43:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19CB091340; Fri, 26 Jul 2002 13:44:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2E3591341; Fri, 26 Jul 2002 13:44:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA01C91340 for ; Fri, 26 Jul 2002 13:44:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE6365DF11; Fri, 26 Jul 2002 13:44:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 38C3C5DD8C for ; Fri, 26 Jul 2002 13:44:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6QGoWw32113; Fri, 26 Jul 2002 09:50:33 -0700 Date: Fri, 26 Jul 2002 09:50:32 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: john.loughney@nokia.com, , Subject: RE: [AAA-WG]: Diameter Base update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I think that this move is at best premature. Allison Mankin (the only IESG > member I could find who had even partially read a recent version of the > draft) has promised to produce a document 'in a couple of weeks' detailing > her objections (if any) to the draft and I think it would be far better to > wait and see what she has to say, instead of just caving in to Randy's > technically unjustified demands. While I am sure that Allison will find additional issues for us to be concerned about, given our previous conversations, I doubt that her additional analysis will absolve us of the need to address the issues that Randy has raised. > Furthermore, I find it difficult to > believe that there is any WG consensus on these changes. WG input is certainly required, and so I would suggest that the best thing is to do a short AAA WG last call on -12, during which we can incorporate additional IESG comments. I'd also like to start WG last call on a revised NASREQ document at the same time, assuming that can be made available. From owner-aaa-wg@merit.edu Fri Jul 26 15:15:27 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 PAA04985 for ; Fri, 26 Jul 2002 15:15:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 778F591341; Fri, 26 Jul 2002 15:15:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D3ED91345; Fri, 26 Jul 2002 15:15:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 360EA91341 for ; Fri, 26 Jul 2002 15:15:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25C4E5DF34; Fri, 26 Jul 2002 15:15:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 2473C5DF36 for ; Fri, 26 Jul 2002 15:15:20 -0400 (EDT) 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 g6QJDed15960 for ; Fri, 26 Jul 2002 22:13:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Jul 2002 22:15:19 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 22:15:17 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 26 Jul 2002 22:15:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update Date: Fri, 26 Jul 2002 22:15:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65802@esebe004.NOE.Nokia.com> Thread-Topic: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update Thread-Index: AcI0rsMer2UB8cTQTZ2oAma9qsmyfAAKVFGQ From: To: Cc: X-OriginalArrivalTime: 26 Jul 2002 19:15:17.0627 (UTC) FILETIME=[C7037CB0:01C234D8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04985 Hi Steve, > >Now, I think that many members of the WG do not see the potential > >interoperability problem introduced by VSCs, and are asking for > >some illustrations on why this is a problem. > > Without going into specific details here -- AAA isn't the only group > where the matter has come up -- the problem is simply that if Vendor A > implements some option of its own invention while Vendor B doesn't have > it, their products won't interoperate smoothly if A's implementation > more or less requires that the option be accepted. > > Clearly, there are gradations. If the optional feature simply improves > efficiency if both sides support it, but the code can fall back to the > standardized -- but less efficient -- mode of operation otherwise, > there's not a problem. The other extreme borders on proprietary > protocols, in which case it isn't clear why the IETF is in that space > to start with. > > The IESG is currently discussing the broader issue. Actually, we (the WG) took great pains to ensure interoperability. Diameter, like SIP, is in many ways, a container protocol. It defines the 'format' and the language for transporting applications to do authorization, authentication & accounting. To use Diameter, one must define an application that is run on top of Diameter. We've tried to engineer it so that we'd avoid nasty interop problems. I think the WG wants to have a better understanding where we have failed, other than a blanket vendor-specific commands are a bad idea. thanks, John From owner-aaa-wg@merit.edu Fri Jul 26 16:18:19 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 QAA07121 for ; Fri, 26 Jul 2002 16:18:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEE1191348; Fri, 26 Jul 2002 16:19:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9B9B91349; Fri, 26 Jul 2002 16:19:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BD3C91348 for ; Fri, 26 Jul 2002 16:17:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F05455DF17; Fri, 26 Jul 2002 16:17:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id 68B1C5DE42 for ; Fri, 26 Jul 2002 16:17:48 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6QKHll05127 for ; Fri, 26 Jul 2002 16:17:47 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA21235; Fri, 26 Jul 2002 15:17:42 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GZVHPG-0001BS-00 for aaa-wg@merit.edu; Fri, 26 Jul 2002 16:17:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15681.44642.714961.862120@gargle.gargle.HOWL> Date: Fri, 26 Jul 2002 15:17:38 -0500 From: Pete McCann To: Subject: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update) In-Reply-To: References: X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Here are my comments on base-12. I think at least some of these issues are outright errors/omissions, while others relate to the ongoing question of experimental/vendor specific application IDs. Please consider this a set of issues for the last call. -Pete Submitter name: Pete McCann Submitter email address: mccap@lucent.com Date first submitted: 26 July 2002 Reference: Document: base Comment type: T/E Priority: 1 Section: 1, 3, and 11 Rationale/Explanation of issue: 1.2.3 Creating New Authentication Applications ... Every Diameter application specification MUST have an IANA assigned Application Identifier (see section 2.4) or a vendor specific Application Identifier. ... 1.2.4 Creating New Accounting Applications ... Every Diameter accounting application specification MUST have an IANA assigned Application Identifier (see section 2.4) a vendor specific Application Identifier. Last paragraph is missing the word "or". Should we say instead, "or a vendor specific experimental Application Identifier."? Or should we delete the last clause, as all Application Identifiers are now assigned by IANA, regardless of whether vendor-specific or not? Also from Section 1.2.4: This is why "disk writing" accounting servers should advertise themselves as "Relays" that can handle any Application ID, including Vendor-Specific. There is an issue with this text that was raised by Glen Zorn but never resolved: I think we mean to say "can handle any *Accounting* Application ID.". A disk-writing accounting server can handle only ACR and ACA, not just any command. Remember, the standards-track application IDs that can appear in CER are split into normal App-IDs and Accounting App-IDs. I think a "disk writing" accounting server should advertise support for the Relay applicationin an Accounting App-ID *only*. Also, I don't think such a server can handle any Vendor-Specific application, because such an application can never include standards-track commands such as ACR/ACA under the current rules, as I understand them. 3.3 Diameter Command Naming Conventions Diameter commands typically includes one or more English words Should be, "Diameter command names typically include" 3 Diameter Header ... Command-Code values in the range 0xfffff0 through 0xffffff are ^^^^^ this is only 16 commands. It's conceivable that even a single application may need more. Should we use 0xffff00 through 0xffffff instead? If so, also need to correct the range in Section 11.2.1. reserved for experimental use. Commands in this range MUST use an IANA-assigned Application ID from the range 0xff00000000 - 0xfffffffe (see Section 11.3). Commands in this range MUST also include a Vendor-Specific Application ID AVP (see section 6.11). Should we clarify here that experimental use = vendor specific? I.e., "Command-Code values in the range 0xfffff0 through 0xffffff are reserved for use by vendor specific, experimental commands." Also, remove extra space between "ID" and "AVP" in the last line. 11.3 Application Identifiers As defined in section 2.4, the Application Identifier is used to identify a specific Diameter Application. There are standards-track application ids and vendor specific application ids. IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0xff00000000 - 0xfffffffe for vendor specific applications. Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. Vendor-Specific Application Identifiers, encoded in the Vendor- Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to the vendor's enterprise number, is for Private Use. I don't think this is strictly true anymore. The Vendor-Specific Application Identifiers are now from the experimental range 0xff00000000 - 0xfffffffe and are in fact managed by IANA. Or perhaps I've misinterpreted the intention here? If the experimental command code space is to be managed by IANA, this IANA Considerations section is inadequate. It needs to give the assignment policy (Expert Review, First-come-first-served, etc.). We could leave the space for Private Use (I actually favor this alternative), but I think that brought up the routing concerns raised by Bernard - then we would need to parse the AVPs to find out how to route the command. Also such a policy conflicts with the language in section 3 under "Command Codes", which I quoted above. From owner-aaa-wg@merit.edu Fri Jul 26 22:26:17 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 WAA15229 for ; Fri, 26 Jul 2002 22:26:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3840B91350; Fri, 26 Jul 2002 22:26:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0326791351; Fri, 26 Jul 2002 22:26:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5994D91350 for ; Fri, 26 Jul 2002 22:26:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4766E5DE28; Fri, 26 Jul 2002 22:26:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id BA4835DE21 for ; Fri, 26 Jul 2002 22:26:42 -0400 (EDT) Received: from GWZW2K (shinjuku-equant-dynamic105.cisco.com [64.104.42.105]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA06694; Fri, 26 Jul 2002 19:26:28 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" Cc: , , Subject: RE: [AAA-WG]: Diameter Base update Date: Fri, 26 Jul 2002 19:26:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > I think that this move is at best premature. Allison Mankin > (the only IESG > > member I could find who had even partially read a recent version of the > > draft) has promised to produce a document 'in a couple of > weeks' detailing > > her objections (if any) to the draft and I think it would be > far better to > > wait and see what she has to say, instead of just caving in to Randy's > > technically unjustified demands. > > While I am sure that Allison will find additional issues for us to be > concerned about, given our previous conversations, I doubt that her > additional analysis will absolve us of the need to address the issues that > Randy has raised. For reference, here is reproduced the entire text of the relevant issue: Issue 268: Diameter Extensibility Submitter name: Randy Bush Submitter email address: randy@psg.com Date first submitted: 29-Dec-01 Reference: Document: Base 08 Comment type: Technical Priority: S Section: Rationale/Explanation of issue: is eeems that the results of the discussion last may of vendor-specific commands never made it into the documents. in specific. --- 25 of the base: "The Command-Code field is three octets, and is used in order to communicate the command associated with the message. The 24-bit address space is managed by IANA (see section 11.2). In the event that the Command-Code field contains a vendor specific command, the four octet Vendor-ID field contains the IANA assigned "SMI Network Management Private Enterprise Codes" [2] value. If the Command-Code field contains an IETF standard Command, the Vendor-ID field MUST be set to zero (0). Any vendor wishing to implement a vendor-specific Diameter command MUST use their own Vendor-ID along with their privately managed Command-Code address space, guaranteeing that they will not collide with any other vnedor's vendor-specific command, nor with future IETF applications." --- as i said last april, > as an engineer, i sympathize with the excitement that the protocol is > very extensible. otoh, an architect might view that the protocol is > merely a list of name/value tuples to indicate a lack of bounding and > understanding of the problems and/or inability to make a real design for > it. > > open loop extensibility is really worrying the iesg. --- and we discussed again in may: > So, the WG questioned whether the specs could be more relax on the > IANA requirements for extensibility. Specifically, could a > vendor-specific extension be created without Standards Action. i can see arguments for relaxing to info but not iana-only. a documentation trail is needed. --- and a number of iesg members made quite clear, or at least tried to, that any extensions, vendor or otherwise, must require previous documentation in an rfc. --- please consider this a bug report. my apologies for not knowing how to get a bug number etc. So the question is, and has been, (please excuse my shouting) WHAT ISSUES? All I can find in the text is rather vague philosophizing. Outside of this "issue", there have been a number of somewhat wild and uniformly spurious claims made about the protocol (e.g., that VSEs may somehow be "mandatory"), but when I and others asked for these "features" to be pointed out (so they might be eradicated), only silence ensued. > > > Furthermore, I find it difficult to > > believe that there is any WG consensus on these changes. > > WG input is certainly required, and so I would suggest that the best thing > is to do a short AAA WG last call on -12, during which we can incorporate > additional IESG comments. Although it seems to be true that in many cases a last call is necessary to get any WG input at alll these days, this doesn't appear to be the case in this instance. There have been several messages (all negative) about this already. > I'd also like to start WG last call on a revised > NASREQ document at the same time, assuming that can be made available. > > > > From owner-aaa-wg@merit.edu Sun Jul 28 13:24: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 NAA29997 for ; Sun, 28 Jul 2002 13:24:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE6E39122E; Sun, 28 Jul 2002 13:25:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B64359123A; Sun, 28 Jul 2002 13:25:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D5069122E for ; Sun, 28 Jul 2002 13:25:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60A2D5E030; Sun, 28 Jul 2002 13:25:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 8AAA35DDB0 for ; Sun, 28 Jul 2002 13:25:50 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6SHOAd28617 for ; Sun, 28 Jul 2002 20:24:10 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 27 Jul 2002 21:40:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 Jul 2002 21:40:53 +0300 Subject: RE: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update Date: Sat, 27 Jul 2002 21:40:51 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EDD@esebe004.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Thread-Topic: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcI04VJ2peZZ9Y/yT3iXplSgCOOKEgAudY+y From: To: Cc: X-OriginalArrivalTime: 27 Jul 2002 18:40:53.0773 (UTC) FILETIME=[23461BD0:01C2359D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id NAA29997 > I here you, and your request is a reasonable one. That said, container > protocols are in a very strong sense the worst kind -- to pick a very > bad, egregiously unfair example, it's almost like saying that we don't > have to worry about email transport, since we have this nice general > transport mechanism called TCP. Understood. glad you brought up TCP. I suspect there is a bigger issue lurking here. One could assume Diameter to be the transport protocol for AAA, and as such, VSCs could potentially cause problems - similar as if TCP had vendor message options. I imagine one of the successes of IP could be attributed to the fact that the basic TCP/IP stack has been fairly stable and has good interoperability. > An answer that "we'll charter more working groups to design Diameter > applications" is a good one. But in that case, the extra command codes > would be standardized in those WGs, not by vendors. Actually, the more I think of it, the more I like having a small experimental range for command codes, beyond the initial use. I do think that allowing for experimentation with protocols is useful & giving a sandbox for implementors to play in, is a useful thing. Of couse, this can be abused, but implememntations abuse TCP & IP anyway. John From owner-aaa-wg@merit.edu Sun Jul 28 18:42: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 SAA03849 for ; Sun, 28 Jul 2002 18:42:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5D4991243; Sun, 28 Jul 2002 18:42:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9793691263; Sun, 28 Jul 2002 18:42:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 426E391243 for ; Sun, 28 Jul 2002 18:42:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 273625DEA4; Sun, 28 Jul 2002 18:42:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 725FA5DDB4 for ; Sun, 28 Jul 2002 18:42:53 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g6SMgqi14730; Sun, 28 Jul 2002 17:42:52 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6SMgqG02496; Sun, 28 Jul 2002 17:42:52 -0500 (CDT) Received: from ericsson.com (racomin-105.exu.ericsson.se [138.85.130.105]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id PV0THK4Q; Sun, 28 Jul 2002 17:42:51 -0500 Message-ID: <3D447256.19BE0D33@ericsson.com> Date: Sun, 28 Jul 2002 15:38:14 -0700 X-Sybari-Trust: 18e6dd58 14dfe396 6eec7111 00000138 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (mail 3) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Bernard Aboba wrote: > ---------- Forwarded message ---------- > Date: Wed, 10 Jul 2002 09:07:58 -0400 > From: Luis A. Sanchez > To: Bernard Aboba , Randy Bush , > "Wijnen, Bert (Bert)" > Subject: Re: FW: request for review from AAA WG > > 2) The following is an example of a > session creation procedure, using MD5 as the hashing algorithm. > Additional algorithms are supported, and listed in [MIPKEYS]. > > MD5(AAA-Key | key material | node-address | AAA-Key) > > Problem: For key derivation, this document recommends using > MD5/prefix+suffix mode. Back in 1996 Bellare, Canetti and Krawczyk > published a paper on crypto discussing how a keyed hash function used in > append/pre-append mode is more susceptible to the "divide and conquer" > attack, although impractical, than a keyed-hashed function using a > keyed-IV instead. They also proved that cryptographic ally HMAC is as > strong as the hash function used with it. One can no make such a > statement with a key-hashed function used in prefix+suffix > mode. As such, IPsec dropped RFC1828 and adopted HMAC-MD5 and HMAC-SHA1 > the latter truncated to 90bits. Another potential problem with > MD5/prefix+suffix could come in if the nonsecret component of the key is > variable length. In that case, if you were using MD5(secret, nonsecret) > = newkey, then someone might be able to see newkey and later observe an > exchange where nonsecret' = nonsecret|1. Then the key would be > MD5(newkey, 1) = newkey'. You have to analyze the protocol very > carefully to assure that this doesn't happen, but if you use HMAC, you > don't have to worry about it. > > **Recommendation: Advise reader to derive keys using: key = > HMAC-MD5(AAA-key, > > {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using > MD5/prefix+suffix. Agreed. In section 5.2 Key Material vs. Session Key: Remove: "... The following is an example of a session creation procedure, using MD5 as the hashing algorithm. Additional algorithms are supported, and listed in [MIPKEYS]. MD5(AAA-Key | key material | node-address | AAA-Key) Where: - AAA-Key is the long term secret shared between the mobile node and the AAAH. - Key material is a random [RANDOM] value of at least 64 bits. - node-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead. ..." Add: "... The following is an example of a session creation procedure, which the Mobile Node has to comply with, using HMAC-MD5 as the hashing algorithm. Additional algorithms are supported, and listed in [MIPKEYS] and from that list the HMAC-MD5 or the HMAC-SHA1 are the recommended algorithms to be used. key = HMAC-MD5(AAA-key,{Key Material | node-address}) Where: - AAA-Key is the long term secret shared between the mobile node and the AAAH. - Key material is a random [RANDOM] value of at least 64 bits. - node-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead." Any comments... BR, /Tony From owner-aaa-wg@merit.edu Sun Jul 28 18:48:12 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 SAA03930 for ; Sun, 28 Jul 2002 18:48:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD6B591263; Sun, 28 Jul 2002 18:48:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7929591264; Sun, 28 Jul 2002 18:48:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C6BE91263 for ; Sun, 28 Jul 2002 18:47:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4605D5DEA4; Sun, 28 Jul 2002 18:47:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 8A8CA5DDB4 for ; Sun, 28 Jul 2002 18:47:53 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g6SMeMi14501; Sun, 28 Jul 2002 17:40:22 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6SMeMo02209; Sun, 28 Jul 2002 17:40:22 -0500 (CDT) Received: from ericsson.com (racomin-105.exu.ericsson.se [138.85.130.105]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id PV0THKRZ; Sun, 28 Jul 2002 17:40:21 -0500 Message-ID: <3D4471BE.E844E8AD@ericsson.com> Date: Sun, 28 Jul 2002 15:35:42 -0700 X-Sybari-Trust: eee075a4 14dfe396 6eec7111 00000138 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: Bernard Aboba Subject: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (mail 1) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Final coming back to this one. Since there are quite a few comments I've split my comments / text proposals into a number of mails, so that we don't drown in one gigantic mail respond. Bernard Aboba wrote: > ---------- Forwarded message ---------- > Date: Wed, 10 Jul 2002 09:07:58 -0400 > From: Luis A. Sanchez > To: Bernard Aboba , Randy Bush , > "Wijnen, Bert (Bert)" > Subject: Re: FW: request for review from AAA WG > > > - There is no explanation on the KDC functionality with message > exchanges in the introduction section. This would help understand the > feature. > > - The KDC part of the protocol is not symmetric. It sends keying > material to the MN and sessions keys to the FA. It is not clear why this > is the case. > Okay how about adding the following new section?: ".in 0 1.6 Key Distribution Center (KDC) .in 3 In order to allow the scaling of wireless data access across administrative domains, it is necessary to minimize the specific security associations required. This means that each Foreign Agent should not be required have a pre-configured shared security association with each Home Agent on the Internet, nor should the mobile node be required to have a pre-configured shared security association with any specific home agent or any specific foreign agent. Diameter Mobile IPv4 application solves this by including a key distribution center (KDC), which means that after a Mobile Node is authenticated, the authorization phase includes the generation of sessions keys. Specifically, three keys are generated and are required by [MOBILEIP]: .in 11 .ti 2 - K1 Key, which will work as security association between the Mobile Node and the Home Agent. .ti 2 - K2 Key, which will work as the security association between the Mobile Node and the Foreign Agent .ti 2 - K3 Key, which will work as the shared between the Foreign Agent and the Home Agent Figure 9 depicts the new security associations used for Mobile-IP message integrity using the keys derived by the DIAMETER server. .in 9 .KS +--------+ +--------+ |Foreign | K3 | Home | |Agent |<-------------------->| Agent | | | | | +--------+ +--------+ ^ ^ | K2 K1 | | +--------+ | | | Mobile | | +------>| Node |<------+ | | +--------+ .in 3 .ce 1 Figure 9 - Security association after key distribution .KE If the home agent is assigned in the home network, each key is generated and encrypted by the home Diameter server. If instead the home agent is assigned in the foreign network the K3 key is generated and encrypted by the foreign networks local Diameter server, while the K1 and K2 is still generated and encrypted by the home Diameter server. The keys destined for the foreign and home agent are propagated to the mobility nodes via the Diameter protocol, and the keys must be encrypted either by IPSec or TLS, when deployed in an environment without Diameter agents, or encrypted by means described in [CMS] when deployed in an environment with Diameter agents. The keys destined for the mobile node must also be propagated via the Mobile IP protocol and must therefore instead follow the encryption mechanisms described in [AAAKEY]. This means that the keys distributed to the mobile node are instead sent as key material, and the mobile node and the home Diameter will use the material and the long term shared secrete to create the keys (see section 5.2). Once the session keys have been established and propagated, the mobility devices can exchange registration information directly as defined in [MOBILEIP] without the need of the Diameter infrastructure. However the session keys have a lifetime, after which the Diameter infrastructure must be invoked again to acquire new session keys." Comments are very appreciated and if some one have any additional text proposals regarding this would be even more appreciated. BR, /Tony From owner-aaa-wg@merit.edu Sun Jul 28 18:48: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 SAA03948 for ; Sun, 28 Jul 2002 18:48:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E404691264; Sun, 28 Jul 2002 18:49:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A994591265; Sun, 28 Jul 2002 18:49:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83AC091264 for ; Sun, 28 Jul 2002 18:49:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FEF75DE71; Sun, 28 Jul 2002 18:49:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id BC8B05DDB4 for ; Sun, 28 Jul 2002 18:49:15 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g6SMfil16881; Sun, 28 Jul 2002 17:41:44 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6SMfiG02402; Sun, 28 Jul 2002 17:41:44 -0500 (CDT) Received: from ericsson.com (racomin-105.exu.ericsson.se [138.85.130.105]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id PV0THKSY; Sun, 28 Jul 2002 17:41:44 -0500 Message-ID: <3D447212.7BAF7489@ericsson.com> Date: Sun, 28 Jul 2002 15:37:06 -0700 X-Sybari-Trust: f95a45d0 14dfe396 6eec7111 00000138 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: Bernard Aboba Subject: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (mail 2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Bernard Aboba wrote: > ---------- Forwarded message ---------- > Date: Wed, 10 Jul 2002 09:07:58 -0400 > From: Luis A. Sanchez > To: Bernard Aboba , Randy Bush , > "Wijnen, Bert (Bert)" > Subject: Re: FW: request for review from AAA WG > > 2) "Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer > (AMA) message, includes the Acct-Multi-Session-Id that was present in > the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs > in the AMA message, enabling appropriate firewall controls for the > penetration of tunneled traffic between the home agent and the mobile > node." > > Problem: The authors mention firewall controls and there is no clear > understanding on what exactly does it mean in this context. For example, > does it means that one of the AVPs will include packet filtering rules > that MUST be implemented in some firewall? If so, what are the selectors > fields for these rules, what entity will push these rules to the > firewall and how one validate the authenticity of the rules. One may > also want to provide confidentiality to such rules. The latter can > piggyback on the existing secured exchanged but it needs some > clarification. As you can see this opens a can of worms. > > Suggestion: Please clarify what is meant by "firewall controls" and > establish the exact operation and security model (if needed). If meant > something different please clarify too. Hmmm, I'm not sure what to do with this one? I guess the question is - should support for packet filtering rules be mandatory to support or not in the mobility agents? 1. If yes, then I guess we only need to clarify that all mobility agents MUST implement support for filtering rules as defined in Base, so that the FA and/or HA will always be able to receive and handle that MIP-Filter-Rule AVPs that may be received in HAR/AMA. 2. If no is the case, thus not requiring that the FAs or the HAs must have firewall support. In this case I think we need some more, like a small new section with something like the following: "1.9 Packet filtering support This application has support for pushing packet filtering roles to either of the mobility agents to enabling appropriate firewall controls for the penetration of tunneled traffic between the home agent and the mobile node. The packet filtering roles are set by the AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if destine to the home agent and/or in the AMA if destine for the foreign agent. If MIP-Filter-Rule AVPs are included in the HAR and the home agent does not have firewall support, the home agent MUST return a HAA with Result-Code AVP equal to DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED. If the MIP-Filter-Rule AVPs are included in the AMA and the foreign agent does not have firewall support, the foreign agent SHOULD log the event and MUST issue a Session-Termination-Request (STR) back to its local Diameter server. ... 3.0 Result-Code AVP Values ... DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 This error code is used by the mobility agent to indicate to the home Diameter server that the requested packet filter roles cannot be supported." Comments are very appreciated and if some one have any additional text proposals regarding this would be even more appreciated. BR, /Tony From owner-aaa-wg@merit.edu Sun Jul 28 19:35: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 TAA04335 for ; Sun, 28 Jul 2002 19:35:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 578DD91266; Sun, 28 Jul 2002 19:36:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2344F9126A; Sun, 28 Jul 2002 19:36:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE71C91266 for ; Sun, 28 Jul 2002 19:36:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96E3F5DDF9; Sun, 28 Jul 2002 19:36:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id D27445DD8D for ; Sun, 28 Jul 2002 19:36:10 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g6SNSei19910; Sun, 28 Jul 2002 18:28:40 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g6SNSev05901; Sun, 28 Jul 2002 18:28:40 -0500 (CDT) Received: from ericsson.com (racomin-105.exu.ericsson.se [138.85.130.105]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id PV0THMCN; Sun, 28 Jul 2002 18:28:39 -0500 Message-ID: <3D447D11.BF4712BE@ericsson.com> Date: Sun, 28 Jul 2002 16:24:01 -0700 X-Sybari-Trust: 612b87d8 14dfe396 6eec7111 00000138 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: Bernard Aboba Subject: [AAA-WG]: Review of draft-ietf-aaa-diameter-mobileip-11.txt (mail 4) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Bernard Aboba wrote: > ---------- Forwarded message ---------- > Date: Wed, 10 Jul 2002 09:07:58 -0400 > From: Luis A. Sanchez > To: Bernard Aboba , Randy Bush , > "Wijnen, Bert (Bert)" > Subject: Re: FW: request for review from AAA WG > > > - The security considerations sections does not provide any > considerations about the KDC feature of the protocol. > S3) "- AAA-Key is the long term secret shared between the mobile > node and the AAAH." > > Problem: The AAA key need to be chosen at random (or using a > cryptographically strong pseudo-random generator seeded with a random > seed), and periodically refreshed. It is not clear that we can > recommended a specific frequency for key changes as the attacks refer to > above may seem practically unfeasible. However, periodic key > refreshment is a fundamental security practice that helps against > potential weaknesses of the function and keys, and limits the damage of > an exposed key. > > **Recommendation: Add a statement to ensure that both the Mobile Node > and the AAA server refresh their shared AAA-key. THis could be done via > the AAA protocol or some other out-of-band mechanism. For in-band > refreshing the new key MUST be encrypted, authenticated and its > integrity MUST be protected while on transit. To solve the above, would something like this be apropriate to add in the consideration section: "10.0 Security Considerations ... This specification also defines a method by which the home Diameter server can create and distribute session keys to be used to authenticate Mobile IP registration messages [MOBILEIP]. The key distribution is asymmetric due to the fact the keys to the mobile node have to be propagated via the mobile IP protocol [AAAKEY, MOBILEIP], while the mobility agent keys are propagated via the Diameter protocol. This means that the keys destine to the mobility agents are always protected by IPSec or TLS as defined in [BASE], when deployed without any Diameter agents, or protected using the methods defined in [CMS], when deployed in an environment that includes Diameter agents. The keys destine for the mobile node are always sent as key material, which is used to derive the actual keys, which means that it does not expose any data that could be used in an attack aimed at recovering the long term key shared between the mobile node and the home Diameter server. Periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key. Therefore, must also the long-term shared secrete between the mobile node and the home Diameter server be periodically refreshed, by utilizing some out-of-band mechanism, since this shared secrete can not be refreshed by any in-band mechanism." Comments are very appreciated and if some one have any additional text proposals regarding this would be even more appreciated. BR, /Tony From owner-aaa-wg@merit.edu Sun Jul 28 21:33: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 VAA05436 for ; Sun, 28 Jul 2002 21:33:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB1699126C; Sun, 28 Jul 2002 21:34:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76BE39127F; Sun, 28 Jul 2002 21:34:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C89C19126C for ; Sun, 28 Jul 2002 21:34:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A18BE5DFFF; Sun, 28 Jul 2002 21:34:31 -0400 (EDT) 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 E188F5DDC4; Sun, 28 Jul 2002 21:34:29 -0400 (EDT) Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id JAA17186; Mon, 29 Jul 2002 09:33:52 +0800 (CST) Received: from PennyGuo ([202.38.197.70]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g6T1KvUB002204; Mon, 29 Jul 2002 09:20:57 +0800 (CST) Message-Id: <200207290120.g6T1KvUB002204@letterbox.scut.edu.cn> Date: Mon, 29 Jul 2002 9:34:30 +0800 From: Penny To: "aaa-wg@merit.edu" Cc: "owner-aaa-wg@merit.edu" Subject: [AAA-WG]: Where is libaaaping.so.1 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 VAA05436 Hi, everyone: I used SUN's aaaapi-example-1.0.1, when I run "runServer.sh", it reports such an error: Unable to open dynamic library libaaaping.so.1 (libaaaping.so.1: cannot open shared object file: No such file or directory)Unable to load dynamic modules I search my machine for libaaaping.so.1, but it seems to unexist. Can anyone help? Thank you. Regards 　　　　　　　　　　　　　　Penny 　　　　　　　　　　　　　　 From owner-aaa-wg@merit.edu Sun Jul 28 21:37: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 VAA05488 for ; Sun, 28 Jul 2002 21:37:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE7719127F; Sun, 28 Jul 2002 21:38:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7817D91288; Sun, 28 Jul 2002 21:38:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C08B9127F for ; Sun, 28 Jul 2002 21:38:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B2E75E043; Sun, 28 Jul 2002 21:38:50 -0400 (EDT) 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 4021B5DDC4 for ; Sun, 28 Jul 2002 21:38:49 -0400 (EDT) Received: (qmail 5399 invoked by uid 500); 29 Jul 2002 01:38:48 -0000 Date: Sun, 28 Jul 2002 20:38:48 -0500 From: David Frascone To: Penny Cc: "aaa-wg@merit.edu" Subject: Re: [AAA-WG]: Where is libaaaping.so.1 Message-ID: <20020729013847.GE15210@newman.frascone.com> Mail-Followup-To: Penny , "aaa-wg@merit.edu" References: <200207290120.g6T1KvUB002204@letterbox.scut.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207290120.g6T1KvUB002204@letterbox.scut.edu.cn> User-Agent: Mutt/1.5.1i Sender: owner-aaa-wg@merit.edu Precedence: bulk This list has nothing to do with Sun's example implementation. But, to answer your question: You have to compile the example code before it will run. Try typing "make". If I remember correctly, that will tell you how to build the code under both linux and Solaris. At http://playground.sun.com/diameter/ There is an e-mail address for who to contact with questions about the implementation. Later, Dave On Monday, 29 Jul 2002, Penny wrote: > Hi, everyone: > I used SUN's aaaapi-example-1.0.1, when I run "runServer.sh", it reports such an error: > Unable to open dynamic library libaaaping.so.1 (libaaaping.so.1: cannot open shared object file: No such file or directory)Unable to load dynamic modules > I search my machine for libaaaping.so.1, but it seems to unexist. Can anyone help? Thank you. > Regards > > ????????????????????????????Penny > ???????????????????????????? -- David Frascone To define recursion, we must first define recursion. From owner-aaa-wg@merit.edu Mon Jul 29 04:19: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 EAA20795 for ; Mon, 29 Jul 2002 04:19:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 127A991277; Mon, 29 Jul 2002 04:20:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C410A9128F; Mon, 29 Jul 2002 04:20:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADD8791277 for ; Mon, 29 Jul 2002 04:20:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 924575E056; Mon, 29 Jul 2002 04:20:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B78785DDDD for ; Mon, 29 Jul 2002 04:20:30 -0400 (EDT) Received: from fmorn1dcode948i (a3.local.ipunplugged.com [192.168.4.173]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g6T8JmUg013830; Mon, 29 Jul 2002 10:19:48 +0200 From: "Fredrik Johansson" To: , , Subject: RE: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update Date: Mon, 29 Jul 2002 10:21:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC657FF@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Hi all, > > To prevent misunderstandings, VSCs were added in Diameter draft -03 > (I think). Shortly after this, Randy Bush (wearing his AD hat) posted > an issue about this. After the last WG last call, Randy said that > as AD, he could not let the spec pass until this issue was resolved. He posted an issue, but he never gave any technical explanation to what the problem is. > > The chairs, ADs, some IESG members and I had several calls to figure > out ways to resolve this & verified that this was OK with 3GPP, via > Stephen Hayes. The resolution of the issue is in the current draft, > version 12. Correct me if I'm wrong, but I thought that the IETF process called for WG consensus, not for consensus from another standardization body. /Fredrik > > Now, I think that many members of the WG do not see the potential > interoperability problem introduced by VSCs, and are asking for > some illustrations on why this is a problem. I would hope that > the WG Chairs & IESG members submit at least an example of how > VSCs could get us into trouble. > > Finally, with regards to 3GPP. I understand that 3GPP has 2 unique > uses of Diameter in their network. These uses should require seperate > applications. Currently, the IETF is allowing the use of experimental > command codes in these applications - I think only one actually requires > them. 3GPP has intended to use vendor extensions for these cases, > but I believe the IESG would prefer to see Internet Standards made > from these applications. I think the next 3GPP release should use > Internet Standards for these applications, which means some additional > work for the AAA WG. After my vacation, I intend to review the existing > drafts & see if I can assist these documents progress to RFC status. > > best regards, > John > > > -----Original Message----- > > From: ext [mailto:Nick.Russell@vf.vodafone.co.uk] > > Sent: 26 July, 2002 13:11 > > To: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Diameter Base update > > > > > > Randy et al, > > > > My interpretation of the agreement that was reached between 3GPP and the > > IETF AAA WG is that the experimental command codes are > something 3GPP can > > *LIVE* with but it has its floors. Particularly if experimental command > > codes "limited lifetime" is only 2 years which I believe was the last > > agreement..? > > > > I would still prefer the original method of Vendor Command > > Codes with IANA > > assigning Vendor IDs which never expire. And I would be interested in > > reading a good technical argument as to why these limited lifetime > > Experimental Command Codes are better than the original Vendor Command > > Codes. As far as I can see, they're going to be worse as the > > lifetime from > > development, through testing, to full deployment/roll-out in > > a network such > > as ours, would be about 2 years! So by the time we've rolled > > it out, it's > > going to be prone to errors. How is this better!? > > > > Cheers, > > Nick > > > > P.S. > > Randy, I think you mean "ad hominem" or probably more specifically > > "argumentative ad hominem" which for those who don't know > > Latin, basically > > means attacking the man instead of the argument. > > > > > -----Original Message----- > > > From: Randy Bush [mailto:randy@psg.com] > > > Sent: 26 July 2002 2:08am > > > To: Glen Zorn > > > Cc: aaa-wg@merit.edu; mankin@isi.edu > > > Subject: RE: [AAA-WG]: Diameter Base update > > > > > > > > > glen, > > > > > > i am having a hard time finding any technical substance in your > > > argument. could you please be more clear? > > > > > > as 3gpp and all other actual users (including prominent cisco folk) > > > have agreed that this is a sufficient forward path, the end of the > > > world does not appear very nigh from this vantage point. and the > > > ad homina are definitely not useful. > > > > > > randy > > > > > > > > > >> I have updated the base spec & sent it to the drafts editor > > > >> for publication. > > > > > > > > I think that this move is at best premature. Allison > > > Mankin (the only IESG > > > > member I could find who had even partially read a recent > > > version of the > > > > draft) has promised to produce a document 'in a couple of > > > weeks' detailing > > > > her objections (if any) to the draft and I think it would > > > be far better to > > > > wait and see what she has to say, instead of just caving in > > > to Randy's > > > > technically unjustified demands. Furthermore, I find it > > > difficult to > > > > believe that there is any WG consensus on these changes. > > > > > > > >> For those of you who want to get an > > > >> early look, it can be grabbed from here: > > > >> > > > >> http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt > > > >> > > > >> The major changes deal with the replacing of Vendor Command > > > >> Codes with Experimental Command codes. Hopefully, the > > > >> change is sufficient & we can send this to the IESG. > > > > > > > > I may be alone on this, but I don't believe that our job as > > > a WG is to twist > > > > and spindle and mutilate our work until it is acceptable to > > > the IESG (in > > > > this case, actually just one IESG member). Rather, our > > > task is to produce > > > > the best work we can _through the rough-consensus based > > > IETF process_ and > > > > submit it. If the IESG refuses to even look at it, then we > > > should abandon > > > > our work, rather than participating in a clear violation of > > > the process. > > > > Let _them_ explain to ITU-T and TIA (not to mention > > > Vodafone, Orange, SK > > > > Telecom, etc.) why they are blocking the deployment of 3G, > > > since they don't > > > > seem to be disposed to explain it to us. > > > > > From owner-aaa-wg@merit.edu Mon Jul 29 07:13:26 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 HAA23878 for ; Mon, 29 Jul 2002 07:13:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58EF391279; Mon, 29 Jul 2002 07:14:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 228EA9128F; Mon, 29 Jul 2002 07:14:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9E9991279 for ; Mon, 29 Jul 2002 07:14:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3F485DE2F; Mon, 29 Jul 2002 07:14:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id 304095DE15 for ; Mon, 29 Jul 2002 07:14:15 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep03-svc.swip.net with ESMTP id <20020729111413.YYWW7098.fep03-svc.swip.net@ipunplugged.com>; Mon, 29 Jul 2002 13:14:13 +0200 Message-ID: <3D454046.1050300@ipunplugged.com> Date: Mon, 29 Jul 2002 13:16:54 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: smb@research.att.com, aaa-wg@merit.edu Subject: Re: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EDD@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >>I here you, and your request is a reasonable one. That said, container >>protocols are in a very strong sense the worst kind -- to pick a very >>bad, egregiously unfair example, it's almost like saying that we don't >>have to worry about email transport, since we have this nice general >>transport mechanism called TCP. >> >> > >Understood. glad you brought up TCP. I suspect there is a bigger issue >lurking here. One could assume Diameter to be the transport protocol >for AAA, and as such, VSCs could potentially cause problems - similar >as if TCP had vendor message options. I imagine one of the successes >of IP could be attributed to the fact that the basic TCP/IP stack has been >fairly stable and has good interoperability. > I guess it was inevitable that we would attempt to discuss this by analogy with TCP/IP. If you are trying for some reason to find similarities between Diameter base protcol and TCP/IP protocols it seems more reasonable to compare it to IP since it defines routing and how to mark contained data so that it can be interpreted, i.e. is a "container protocol". I'm not sure TCP/IP is a relevant comparison though, no matter how successful a protocol suite that is. And note that it *is* a suite defined within the framework of the container protocol IP. I don't think I understand the email transport example. Email *is* almost exclusively transported using TCP, but of course with the help of a specific protocol that is embedded within TCP. I am not aware of SMTP being accused of creating interoperability problems and yet an SMTP client most certainly does not interoperate very well with an FTP or HTTP server. It seems to me that one cause of the concern is a lack of understanding that you can't just toss in a few new VSCs at random times. They live in vendor specific applications and as such are orthogonal to the functionality of already defined commands. Being afraid of VSCs but accepting vendor specific avps seems strange to me. Another cause seems to be that somehow the Diameter base protocol is expected to be "the protocol" but it performs no real work. That is the task of specific applications, such as NASREQ, MIP and CMS. These have not yet been submitted as far as I know. >>An answer that "we'll charter more working groups to design Diameter >>applications" is a good one. But in that case, the extra command codes >>would be standardized in those WGs, not by vendors. >> >> > >Actually, the more I think of it, the more I like having a small experimental >range for command codes, beyond the initial use. I do think that allowing >for experimentation with protocols is useful & giving a sandbox for >implementors to play in, is a useful thing. Of couse, this can be abused, >but implememntations abuse TCP & IP anyway. > > > And what better way to encourage implementors to experiment than by giving them their own namespace to play around in? In what way would it be better to merge all vendors' namespaces? Where is the improvement? I have of course no problem with IETF chartering more working groups to design Diameter applications when they are needed, but I fail to see why they would want to standardize highly implementation specific things such as how to exchange node state within a cluster. Why forbid the vendors from solving this within the protocol? j From owner-aaa-wg@merit.edu Mon Jul 29 14:08: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 OAA09390 for ; Mon, 29 Jul 2002 14:08:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B64CF9126B; Mon, 29 Jul 2002 14:08:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81EB691282; Mon, 29 Jul 2002 14:08:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E91A9126B for ; Mon, 29 Jul 2002 14:08:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA0EE5DE55; Mon, 29 Jul 2002 14:08:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by segue.merit.edu (Postfix) with ESMTP id 8E0BA5DDA4 for ; Mon, 29 Jul 2002 14:08:54 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6TI8cS29635; Mon, 29 Jul 2002 14:08:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 14:08:38 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A702@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Johan Johansson'" , Randy Bush Cc: Glen Zorn , aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter Base update Date: Mon, 29 Jul 2002 14:08:35 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm getting a bit impatient with this. The technical argument has been made already: the IETF wants to retain control of the architecture of the protocols it has developed. That has been said plainly both with respect to SIP and with respect to DIAMETER. Now, can you provide a technical counter-argument that it is impossible to change a protocol architecture merely by adding new commands? -----Original Message----- From: Johan Johansson [mailto:johanj@ipunplugged.com] Sent: Friday, July 26, 2002 8:02 AM To: Randy Bush Cc: Glen Zorn; aaa-wg@merit.edu; mankin@isi.edu Subject: Re: [AAA-WG]: Diameter Base update As far as I know 3gpp had no problem with the original solution either. In fact, you are the only one who has ever *had* a problem with it, and you refuse to tell us what the problem is. Did you really ask "all other actual users"? Are you sure you didn't miss some? Also, I beg to differ that this is a sufficient forward path. Merging the command code namespaces is a backward path. Since this is to be an IETF standard it would seem more important that the workgroup agrees with the solution than anyone else. Glen's mail doesn't have technical substance since it's not about technical matters but about how to repair your blatant breach of IETF process, i.e. it does not express a technological argument but an administrative one. Even had it been lacking technical substance where such was merited, your first priority should be to explain your mysterious aversion to vendor specific commands and show why they are dangerous. This is and has been your task for the last month(s). John, you have submitted a draft that you know there is not only no workgroup consenus around, but rather there is workgroup opposition. Until Randy produces a solid case for his objections that will turn the workgroup's opinion in his favour, and note that I am still not excluding this possibility, the problem does not exist. If he refuses to pass the draft on without explaining in an acceptable way why he does so, we can always find another way to get it to the IESG. j Randy Bush wrote: >glen, > >i am having a hard time finding any technical substance in your >argument. could you please be more clear? > >as 3gpp and all other actual users (including prominent cisco folk) >have agreed that this is a sufficient forward path, the end of the >world does not appear very nigh from this vantage point. and the >ad homina are definitely not useful. > >randy > > > > >>>I have updated the base spec & sent it to the drafts editor >>>for publication. >>> >>> >>I think that this move is at best premature. Allison Mankin (the only IESG >>member I could find who had even partially read a recent version of the >>draft) has promised to produce a document 'in a couple of weeks' detailing >>her objections (if any) to the draft and I think it would be far better to >>wait and see what she has to say, instead of just caving in to Randy's >>technically unjustified demands. Furthermore, I find it difficult to >>believe that there is any WG consensus on these changes. >> >> >> >>>For those of you who want to get an >>>early look, it can be grabbed from here: >>> >>>http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt >>> >>>The major changes deal with the replacing of Vendor Command >>>Codes with Experimental Command codes. Hopefully, the >>>change is sufficient & we can send this to the IESG. >>> >>> >>I may be alone on this, but I don't believe that our job as a WG is to twist >>and spindle and mutilate our work until it is acceptable to the IESG (in >>this case, actually just one IESG member). Rather, our task is to produce >>the best work we can _through the rough-consensus based IETF process_ and >>submit it. If the IESG refuses to even look at it, then we should abandon >>our work, rather than participating in a clear violation of the process. >>Let _them_ explain to ITU-T and TIA (not to mention Vodafone, Orange, SK >>Telecom, etc.) why they are blocking the deployment of 3G, since they don't >>seem to be disposed to explain it to us. >> >> > > >