From owner-aaa-wg@merit.edu Mon Jun 3 15:44: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 PAA28820 for ; Mon, 3 Jun 2002 15:44:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1A4C91201; Mon, 3 Jun 2002 15:44:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 897AA9120E; Mon, 3 Jun 2002 15:44: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 958B891201 for ; Mon, 3 Jun 2002 15:44:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E38A75DEC4; Mon, 3 Jun 2002 15:44:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9F95C5DEC2 for ; Mon, 3 Jun 2002 15:44:30 -0400 (EDT) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id E51857E; Mon, 3 Jun 2002 15:44:37 -0400 (EDT) Message-ID: <3CFBC769.A32542FA@Interlinknetworks.com> Date: Mon, 03 Jun 2002 15:45:45 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I've had my head buried in NASREQ too long. I let this one slide by without picking up on it. Johan has identified a real problem in issue 336, but I believe he has proposed the wrong solution to it. There is a very important reason why the accounting Session-Id should be the same as the authorization Session-Id. It's to facilitate auditing. It ought to be possible to verify in an audit that sessions accounted for were, in fact, authorized. Including the same Session-Id in authorization and accounting messages has been a key concept of Diameter since the beginning. We should not even propose changing something this basic this late in the process. But in this case, we really can't. The Session-Id MUST be the same for both the authorization and accounting messages. However, since the issue is a real one, it must be solved somehow. The following is my proposal. 1) In the MIP draft, we should require that the HAR has the same Session-Id as the AMR that caused it to be generated. As a result of this protocol change, a) the session scope seen by the HA will match the session scope seen by the FAs, the AAAFs, and the AAAHs, b) the AAAH does not need to be session-stateful, and c) it makes no difference whether all the HARs are issued by the same AAAH or not. This change also allows us to remove the following nonsensical statements from section 1.2 of the MIP draft: If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR. The nonsense consists of making a protocol requirement conditional on an implementation decision (if session-stateful, then MUST send same Session-Id). And of what use is the MUST if the HA can't depend on it? 2) When an HA receives an HAR for a given multi-session that has a different Session-Id from previous HARs for the same multi-session, the HA MUST generate an ACR with an Accounting-Record-Type of STOP_RECORD containing the old Session-Id followed by an ACR with an Accounting-Record-Type of START_RECORD containing the new Session-Id. As a result of this protocol change, a) HA accounting sessions will have the same scope as FA accounting sessions so that the records could be matched by an accounting server if desired, and b) FA and HA accounting records will contain the same Session-Id to facilitate such matching as well as to facilitate auditing. David S. john.loughney@nokia.com wrote: > > Hi all, > > I have made the changes, so issue 336 is closed. > > John > > > -----Original Message----- > > From: Loughney John (NRC/Helsinki) > > Sent: 02 May, 2002 10:32 > > To: johanj@ipunplugged.com; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and > > accounting sessions > > > > > > Hi Johan, > > > > > Requested change: > > > > > > The Diameter protocol's Session-Id AVP, which is > > globally unique (see > > > section 8.8), is used during the authorization phase to > > identify a > > > particular session. Services that do not require any > > authorization > > > still use the Session-Id AVP to identify sessions. > > > > > > to > > > > > > The Diameter protocol's Session-Id AVP, which is globally > > unique (see > > > section 8.8), is used during the authorization phase to identify a > > > particular session. Services that do not require any authorization > > > still use the Session-Id AVP to identify sessions. > > Accounting messages > > > MUST use a different Session-Id from that sent in > > > authorization messages. > > > > Somehow, the "MUST use" part of the last sentence worries me. I think > > that it may be more application specific. I'd prefer to > > state something > > more like: > > > > Accounting messages MAY use a different Session-Id from > > that sent in > > authorization messages. Specific applications MAY require different > > a Session-ID for accounting messages. > > > > Then, the application (for example MIP) could use a MUST. > > > > Comments? > > John > > > > -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Mon Jun 3 18:58: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 SAA03626 for ; Mon, 3 Jun 2002 18:58:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 384A691208; Mon, 3 Jun 2002 18:58:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 020909120C; Mon, 3 Jun 2002 18:58:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD95B91208 for ; Mon, 3 Jun 2002 18:58:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32F115DE35; Mon, 3 Jun 2002 18:58:14 -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 E0C695DD8D for ; Mon, 3 Jun 2002 18:58:13 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g53MwKl29597; Mon, 3 Jun 2002 17:58:20 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g53MwKf24212; Mon, 3 Jun 2002 17:58:20 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA14187; Mon, 3 Jun 2002 17:58:19 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA29337; Mon, 3 Jun 2002 17:58:18 -0500 (CDT) Message-ID: <3CFBF3A8.332BDEBA@ericsson.com> Date: Mon, 03 Jun 2002 15:54:32 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, David Spence wrote: > I've had my head buried in NASREQ too long. I let this one slide by > without picking up on it. Johan has identified a real problem in issue > 336, but I believe he has proposed the wrong solution to it. There is a > very important reason why the accounting Session-Id should be the same as > the authorization Session-Id. It's to facilitate auditing. It ought to > be possible to verify in an audit that sessions accounted for were, in > fact, authorized. Including the same Session-Id in authorization and > accounting messages has been a key concept of Diameter since the > beginning. We should not even propose changing something this basic > this late in the process. But in this case, we really can't. The > Session-Id MUST be the same for both the authorization and accounting > messages. Since the nature of MIP is that you move between FAs and as stated in the MIP draft: " .... A mobile node's session is identified via its identity in the User- Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address AVPs. This is necessary in order to allow the session state machine, defined in the base protocol [DIAMBASE], to be used unmodified with this application. Therefore, an STR from a foreign agent would free the session from the foreign agent, but not the one towards the home agent (see figure 3). STR, Session-Id = foo STR, Session-Id = bar ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> STA, Session-Id = foo STA, Session-Id = bar Figure 3: Session Termination and Session Identifiers " > > > However, since the issue is a real one, it must be solved somehow. The > following is my proposal. > > 1) In the MIP draft, we should require that the HAR has the same > Session-Id as the AMR that caused it to be generated. As a result of > this protocol change, This was discussed about a year a go and identified that the Session-Id for the AMR and the HAR MUST be different. What you are raising here is an old issue, so I really don't see why we should go here again. Furthermore, the functionality that you mention in bullet 1 and 2 are already fulfilled today, with help of the Acct-Multi-Session-Id, see e.g. section 1.3 Support for Mobile IP Handoffs: "... Since the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node, with a new session identifier, and the HA can guarantee that this request is to extend service for an existing service, then the HA MUST be able to modify its internal session state information to reflect the new session identifier. It is necessary for accounting records to have some commonality across handoffs in order for correlation to occur. Therefore, the home agent MUST send the same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Acct-Multi-Session-Id when receiving an HAR for a new session, and returns this same value in every HAA for the session. This Acct- Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Acct-Multi-Session-Id in the accounting messages. ACR, Session-Id = foo ACR, Session-Id = bar Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a ---------------------> <-------------------- +----+ +------+ +------+ +----+ | FA | | AAAF | | AAAH | | HA | +----+ +------+ +------+ +----+ <--------------------- ---------------------> ACA, Session-Id = foo ACA, Session-Id = bar Figure 4: Accounting messages w/ Mobile IP Application ..." So, the HARs session-Id may change, but the acct-multi-session-id stays the same for both the HA and FAs. You can also look at issue Issue 290: Handling of Acct-Multi-Session-Id AVP, which was discussed and solved in February. Again, the draft has already this functionality (by the Acct-Multi-Session-Id AV.), so MHO I really don't see why we should discuss this any further, and most likely postpone the time line for this draft even further. /Tony > > > a) the session scope seen by the HA will match the session scope > seen by the FAs, the AAAFs, and the AAAHs, > > b) the AAAH does not need to be session-stateful, and > > c) it makes no difference whether all the HARs are issued by the > same AAAH or not. > > This change also allows us to remove the following nonsensical > statements from section 1.2 of the MIP draft: > > If the AAAH is session-stateful, it MUST send the same session > identifier for all HARs initiated on behalf of a given mobile > node's session. Otherwise, if the AAAH is session-stateless, it > will manufacture a unique session-id for every HAR. > > The nonsense consists of making a protocol requirement conditional on > an implementation decision (if session-stateful, then MUST send same > Session-Id). And of what use is the MUST if the HA can't depend on > it? > > 2) When an HA receives an HAR for a given multi-session that has a > different Session-Id from previous HARs for the same multi-session, > the HA MUST generate an ACR with an Accounting-Record-Type of > STOP_RECORD containing the old Session-Id followed by an ACR with an > Accounting-Record-Type of START_RECORD containing the new Session-Id. > > As a result of this protocol change, > > a) HA accounting sessions will have the same scope as FA > accounting sessions so that the records could be matched by an > accounting server if desired, and > > b) FA and HA accounting records will contain the same Session-Id > to facilitate such matching as well as to facilitate auditing. > > David S. > > john.loughney@nokia.com wrote: > > > > Hi all, > > > > I have made the changes, so issue 336 is closed. > > > > John > > > > > -----Original Message----- > > > From: Loughney John (NRC/Helsinki) > > > Sent: 02 May, 2002 10:32 > > > To: johanj@ipunplugged.com; aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and > > > accounting sessions > > > > > > > > > Hi Johan, > > > > > > > Requested change: > > > > > > > > The Diameter protocol's Session-Id AVP, which is > > > globally unique (see > > > > section 8.8), is used during the authorization phase to > > > identify a > > > > particular session. Services that do not require any > > > authorization > > > > still use the Session-Id AVP to identify sessions. > > > > > > > > to > > > > > > > > The Diameter protocol's Session-Id AVP, which is globally > > > unique (see > > > > section 8.8), is used during the authorization phase to identify a > > > > particular session. Services that do not require any authorization > > > > still use the Session-Id AVP to identify sessions. > > > Accounting messages > > > > MUST use a different Session-Id from that sent in > > > > authorization messages. > > > > > > Somehow, the "MUST use" part of the last sentence worries me. I think > > > that it may be more application specific. I'd prefer to > > > state something > > > more like: > > > > > > Accounting messages MAY use a different Session-Id from > > > that sent in > > > authorization messages. Specific applications MAY require different > > > a Session-ID for accounting messages. > > > > > > Then, the application (for example MIP) could use a MUST. > > > > > > Comments? > > > John > > > > > > > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Mon Jun 3 21:20: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 VAA05374 for ; Mon, 3 Jun 2002 21:20:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44C269120E; Mon, 3 Jun 2002 21:20:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1090991218; Mon, 3 Jun 2002 21:20: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 D28579120E for ; Mon, 3 Jun 2002 21:20:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40C2A5DE9B; Mon, 3 Jun 2002 21:20:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 287145DE6E for ; Mon, 3 Jun 2002 21:20:18 -0400 (EDT) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 677EC7D; Mon, 3 Jun 2002 21:20:25 -0400 (EDT) Message-ID: <3CFC161D.6624C24@Interlinknetworks.com> Date: Mon, 03 Jun 2002 21:21:33 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, I am aware of the function of the Acct-Multi-Session-Id, and you are correct that it binds the sessions of the multi-session together. What I was trying to do was to preserve Diameter's notion of a session and salvage the function of a Session-Id, which ought to bind the messages within a session together and ought to be useful for purposes such as auditing, independent of application. Session-Id should not work differently for MIP than it does for other Diameter applications. Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. The Acct-Multi-Session-Id AVP is not included in every MIP message. The Session-Id AVP is. You are correct that my proposal failed to address the termination of the individual authorization sessions. Unfortunately, MIP, as it is, is simply broken. Not only don't HA sessions correspond to FA sessions. In mobileip-10, they also have no identifier that appears in every message of the session. And there is no mechanism to identify sessions between the HA and the various AAAH's that may be involved. I believe MIP is a faulty extension of Diameter if HA sessions cannot be identified using the base protocol. Therefore, I'm afraid issue 336 is still unresolved, and now we have a new issue regarding the brokeness of HA sessions. That's more than I want to try to fix tonight so, in the words of Scarlett O'Hara, I'll worry about that tomorrow. Dave Tony Johansson wrote: > > Hi David, > > David Spence wrote: > > > I've had my head buried in NASREQ too long. I let this one slide by > > without picking up on it. Johan has identified a real problem in issue > > 336, but I believe he has proposed the wrong solution to it. There is a > > very important reason why the accounting Session-Id should be the same as > > the authorization Session-Id. It's to facilitate auditing. It ought to > > be possible to verify in an audit that sessions accounted for were, in > > fact, authorized. Including the same Session-Id in authorization and > > accounting messages has been a key concept of Diameter since the > > beginning. We should not even propose changing something this basic > > this late in the process. But in this case, we really can't. The > > Session-Id MUST be the same for both the authorization and accounting > > messages. > > Since the nature of MIP is that you move between FAs and as stated in the MIP > draft: > > " > .... > A mobile node's session is identified via its identity in the User- > Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address > AVPs. This is necessary in order to allow the session state machine, > defined in the base protocol [DIAMBASE], to be used unmodified with > this application. Therefore, an STR from a foreign agent would free > the session from the foreign agent, but not the one towards the home > agent (see figure 3). > > STR, Session-Id = foo STR, Session-Id = bar > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > STA, Session-Id = foo STA, Session-Id = bar > Figure 3: Session Termination and Session Identifiers " > > > > > > > However, since the issue is a real one, it must be solved somehow. The > > following is my proposal. > > > > 1) In the MIP draft, we should require that the HAR has the same > > Session-Id as the AMR that caused it to be generated. As a result of > > this protocol change, > > This was discussed about a year a go and identified that the Session-Id for the > AMR and the HAR MUST be different. What you are raising here is an old issue, so > I really don't see why we should go here again. > > Furthermore, the functionality that you mention in bullet 1 and 2 are already > fulfilled today, with help of the Acct-Multi-Session-Id, see e.g. section 1.3 > Support for Mobile IP Handoffs: > > "... > Since the AAAH may be session-stateless, it is necessary for the > resulting HAR received by the HA to be identified as a continuation > of an existing session. If the HA receives an HAR for a mobile node, > with a new session identifier, and the HA can guarantee that this > request is to extend service for an existing service, then the HA > MUST be able to modify its internal session state information to > reflect the new session identifier. > > It is necessary for accounting records to have some commonality > across handoffs in order for correlation to occur. Therefore, the > home agent MUST send the same Acct-Multi-Session-Id AVP value in all > HAAs for the mobile's session. That is, the HA generates a unique > Acct-Multi-Session-Id when receiving an HAR for a new session, and > returns this same value in every HAA for the session. This Acct- > Multi-Session-Id AVP will be returned to the foreign agent by the > AAAH in the AMA. Both the foreign and home agents MUST include the > Acct-Multi-Session-Id in the accounting messages. > > ACR, Session-Id = foo ACR, Session-Id = bar > Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a > ---------------------> <-------------------- > +----+ +------+ +------+ +----+ > | FA | | AAAF | | AAAH | | HA | > +----+ +------+ +------+ +----+ > <--------------------- ---------------------> > ACA, Session-Id = foo ACA, Session-Id = bar > > Figure 4: Accounting messages w/ Mobile IP Application > ..." > > So, the HARs session-Id may change, but the acct-multi-session-id stays the same > for both the HA and FAs. You can also look at issue Issue 290: Handling of > Acct-Multi-Session-Id AVP, which was discussed and solved in February. > > Again, the draft has already this functionality (by the Acct-Multi-Session-Id > AV.), so MHO I really don't see why we should discuss this any further, and most > likely postpone the time line for this draft even further. > > /Tony > > > > > > > a) the session scope seen by the HA will match the session scope > > seen by the FAs, the AAAFs, and the AAAHs, > > > > b) the AAAH does not need to be session-stateful, and > > > > c) it makes no difference whether all the HARs are issued by the > > same AAAH or not. > > > > This change also allows us to remove the following nonsensical > > statements from section 1.2 of the MIP draft: > > > > If the AAAH is session-stateful, it MUST send the same session > > identifier for all HARs initiated on behalf of a given mobile > > node's session. Otherwise, if the AAAH is session-stateless, it > > will manufacture a unique session-id for every HAR. > > > > The nonsense consists of making a protocol requirement conditional on > > an implementation decision (if session-stateful, then MUST send same > > Session-Id). And of what use is the MUST if the HA can't depend on > > it? > > > > 2) When an HA receives an HAR for a given multi-session that has a > > different Session-Id from previous HARs for the same multi-session, > > the HA MUST generate an ACR with an Accounting-Record-Type of > > STOP_RECORD containing the old Session-Id followed by an ACR with an > > Accounting-Record-Type of START_RECORD containing the new Session-Id. > > > > As a result of this protocol change, > > > > a) HA accounting sessions will have the same scope as FA > > accounting sessions so that the records could be matched by an > > accounting server if desired, and > > > > b) FA and HA accounting records will contain the same Session-Id > > to facilitate such matching as well as to facilitate auditing. > > > > David S. > > > > john.loughney@nokia.com wrote: > > > > > > Hi all, > > > > > > I have made the changes, so issue 336 is closed. > > > > > > John > > > > > > > -----Original Message----- > > > > From: Loughney John (NRC/Helsinki) > > > > Sent: 02 May, 2002 10:32 > > > > To: johanj@ipunplugged.com; aaa-wg@merit.edu > > > > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and > > > > accounting sessions > > > > > > > > > > > > Hi Johan, > > > > > > > > > Requested change: > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is > > > > globally unique (see > > > > > section 8.8), is used during the authorization phase to > > > > identify a > > > > > particular session. Services that do not require any > > > > authorization > > > > > still use the Session-Id AVP to identify sessions. > > > > > > > > > > to > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is globally > > > > unique (see > > > > > section 8.8), is used during the authorization phase to identify a > > > > > particular session. Services that do not require any authorization > > > > > still use the Session-Id AVP to identify sessions. > > > > Accounting messages > > > > > MUST use a different Session-Id from that sent in > > > > > authorization messages. > > > > > > > > Somehow, the "MUST use" part of the last sentence worries me. I think > > > > that it may be more application specific. I'd prefer to > > > > state something > > > > more like: > > > > > > > > Accounting messages MAY use a different Session-Id from > > > > that sent in > > > > authorization messages. Specific applications MAY require different > > > > a Session-ID for accounting messages. > > > > > > > > Then, the application (for example MIP) could use a MUST. > > > > > > > > Comments? > > > > John > > > > > > > > > > > > -- > > David Spence email: DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: +1 734 821 1203 > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > Ann Arbor, MI 48108 > > U.S.A. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Tue Jun 4 03:26: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 DAA20395 for ; Tue, 4 Jun 2002 03:26:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85EBB91218; Tue, 4 Jun 2002 03:26:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4783F91220; Tue, 4 Jun 2002 03:26: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 AF9E591218 for ; Tue, 4 Jun 2002 03:26:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F3845DE6C; Tue, 4 Jun 2002 03:26:52 -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 1B12F5DDB8 for ; Tue, 4 Jun 2002 03:26:51 -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 g547RNq29085 for ; Tue, 4 Jun 2002 10:27:23 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Jun 2002 10:26:57 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Jun 2002 10:26:57 +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]: [issue] Clarify relationship between auth and accounting sessions Date: Tue, 4 Jun 2002 10:26:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652F9@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Thread-Index: AcILZgK4KAcpNUlzRBS4X5dpDuwtdwAMq8rQ From: To: , Cc: , X-OriginalArrivalTime: 04 Jun 2002 07:26:57.0182 (UTC) FILETIME=[354B3BE0:01C20B99] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20395 David, Base-11 says: Accounting messages MAY use a different Session-Id from that sent in authorization messages. Specific applications MAY require different a Session-ID for accounting messages. > I am aware of the function of the Acct-Multi-Session-Id, and you are correct > that it binds the sessions of the multi-session together. What I was trying to > do was to preserve Diameter's notion of a session and salvage the function of a > Session-Id, which ought to bind the messages within a session together and ought > to be useful for purposes such as auditing, independent of application. > Session-Id should not work differently for MIP than it does for other Diameter > applications. Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. > The Acct-Multi-Session-Id AVP is not included in every MIP message. The > Session-Id AVP is. > > You are correct that my proposal failed to address the termination of the > individual authorization sessions. Unfortunately, MIP, as it is, is simply > broken. Not only don't HA sessions correspond to FA sessions. In mobileip-10, > they also have no identifier that appears in every message of the session. And > there is no mechanism to identify sessions between the HA and the various AAAH's > that may be involved. I believe MIP is a faulty extension of Diameter if HA > sessions cannot be identified using the base protocol. > > Therefore, I'm afraid issue 336 is still unresolved, and now we have a new issue > regarding the brokeness of HA sessions. That's more than I want to try to fix > tonight so, in the words of Scarlett O'Hara, I'll worry about that tomorrow. MAY is fairly weak, my assumption is that the base-11 is stating that session-id's should be the same for accounting & authorization. What would you prefer the text to say? Would: Accounting messages SHOULD NOT use a different Session-Id from that sent in authorization messages. However, specific applications MAY require different a Session-ID for accounting messages. Is that any better? John From owner-aaa-wg@merit.edu Tue Jun 4 12:56:16 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 MAA05868 for ; Tue, 4 Jun 2002 12:56:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1ACAB91241; Tue, 4 Jun 2002 12:56:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D48DD91242; Tue, 4 Jun 2002 12:56: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 A7F8C91241 for ; Tue, 4 Jun 2002 12:56:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3EF765DEB1; Tue, 4 Jun 2002 12:56:17 -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 E94895DDDF for ; Tue, 4 Jun 2002 12:56:16 -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 g54GuNl21497; Tue, 4 Jun 2002 11:56:24 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g54GuNa18919; Tue, 4 Jun 2002 11:56:23 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA18770; Tue, 4 Jun 2002 11:56:23 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA12356; Tue, 4 Jun 2002 11:56:22 -0500 (CDT) Message-ID: <3CFCF054.414B78F2@ericsson.com> Date: Tue, 04 Jun 2002 09:52:36 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: DSpence@Interlinknetworks.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC652F9@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, john.loughney@nokia.com wrote: > David, > > Base-11 says: > > Accounting messages MAY use a different Session-Id from that > sent in authorization messages. Specific applications MAY require > different a Session-ID for accounting messages. > > > I am aware of the function of the Acct-Multi-Session-Id, and you are correct > > that it binds the sessions of the multi-session together. What I was trying to > > do was to preserve Diameter's notion of a session and salvage the function of a > > Session-Id, which ought to bind the messages within a session together and ought > > to be useful for purposes such as auditing, independent of application. > > Session-Id should not work differently for MIP than it does for other Diameter > > applications. Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. > > The Acct-Multi-Session-Id AVP is not included in every MIP message. The > > Session-Id AVP is. > > > > You are correct that my proposal failed to address the termination of the > > individual authorization sessions. Unfortunately, MIP, as it is, is simply > > broken. Not only don't HA sessions correspond to FA sessions. In mobileip-10, > > they also have no identifier that appears in every message of the session. And > > there is no mechanism to identify sessions between the HA and the various AAAH's > > that may be involved. I believe MIP is a faulty extension of Diameter if HA > > sessions cannot be identified using the base protocol. > > > > Therefore, I'm afraid issue 336 is still unresolved, and now we have a new issue > > regarding the brokeness of HA sessions. That's more than I want to try to fix > > tonight so, in the words of Scarlett O'Hara, I'll worry about that tomorrow. > > MAY is fairly weak, my assumption is that the base-11 is stating that > session-id's should be the same for accounting & authorization. What would > you prefer the text to say? Would: > > Accounting messages SHOULD NOT use a different Session-Id from that > sent in authorization messages. However, specific applications MAY require > different a Session-ID for accounting messages. > > Is that any better? I strongly disagree. The text you have in Base is correct and should not be changed.. /Tony > > > John From owner-aaa-wg@merit.edu Tue Jun 4 13:16: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 NAA06508 for ; Tue, 4 Jun 2002 13:16:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F22091245; Tue, 4 Jun 2002 13:15:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CC9D91246; Tue, 4 Jun 2002 13:15: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 C429E91245 for ; Tue, 4 Jun 2002 13:15:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 535A05DE16; Tue, 4 Jun 2002 13:15:30 -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 04DD95DDE2 for ; Tue, 4 Jun 2002 13:15:30 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g54HFal02798; Tue, 4 Jun 2002 12:15:37 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g54HFav06024; Tue, 4 Jun 2002 12:15:36 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA19456; Tue, 4 Jun 2002 12:15:36 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA12675; Tue, 4 Jun 2002 12:15:35 -0500 (CDT) Message-ID: <3CFCF4D4.9E7B34CA@ericsson.com> Date: Tue, 04 Jun 2002 10:11:49 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, David Spence wrote: > Tony, > > I am aware of the function of the Acct-Multi-Session-Id, and you are correct > that it binds the sessions of the multi-session together. What I was trying to > do was to preserve Diameter's notion of a session and salvage the function of a > Session-Id, which ought to bind the messages within a session together and ought > to be useful for purposes such as auditing, independent of application. > Session-Id should not work differently for MIP than it does for other Diameter > applications. Well, MIP is very different then NASREQ, since you do have to deal with the fact that the MN moves between different FAs, but stays anchored in the same HA in MIP. So, to be able to use Base functionality such as STR/STA, the Session-id is split between the FA and AAAH, and the HA and AAAH. This was decided over a year ago. > Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. > The Acct-Multi-Session-Id AVP is not included in every MIP message. Yes it is! The Acct-Multi-Session-Id is always sent in HAA and AMA, see my previous text below. However, the ABNF in MIP-10 for HAA and AMA is wrong, should be {} and not []. I will fix that in -11. /Tony > The > Session-Id AVP is. > > You are correct that my proposal failed to address the termination of the > individual authorization sessions. Unfortunately, MIP, as it is, is simply > broken. Not only don't HA sessions correspond to FA sessions. In mobileip-10, > they also have no identifier that appears in every message of the session. And > there is no mechanism to identify sessions between the HA and the various AAAH's > that may be involved. I believe MIP is a faulty extension of Diameter if HA > sessions cannot be identified using the base protocol. > > Therefore, I'm afraid issue 336 is still unresolved, and now we have a new issue > regarding the brokeness of HA sessions. That's more than I want to try to fix > tonight so, in the words of Scarlett O'Hara, I'll worry about that tomorrow. > > Dave > > Tony Johansson wrote: > > > > Hi David, > > > > David Spence wrote: > > > > > I've had my head buried in NASREQ too long. I let this one slide by > > > without picking up on it. Johan has identified a real problem in issue > > > 336, but I believe he has proposed the wrong solution to it. There is a > > > very important reason why the accounting Session-Id should be the same as > > > the authorization Session-Id. It's to facilitate auditing. It ought to > > > be possible to verify in an audit that sessions accounted for were, in > > > fact, authorized. Including the same Session-Id in authorization and > > > accounting messages has been a key concept of Diameter since the > > > beginning. We should not even propose changing something this basic > > > this late in the process. But in this case, we really can't. The > > > Session-Id MUST be the same for both the authorization and accounting > > > messages. > > > > Since the nature of MIP is that you move between FAs and as stated in the MIP > > draft: > > > > " > > .... > > A mobile node's session is identified via its identity in the User- > > Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address > > AVPs. This is necessary in order to allow the session state machine, > > defined in the base protocol [DIAMBASE], to be used unmodified with > > this application. Therefore, an STR from a foreign agent would free > > the session from the foreign agent, but not the one towards the home > > agent (see figure 3). > > > > STR, Session-Id = foo STR, Session-Id = bar > > ---------------------> <-------------------- > > +----+ +------+ +------+ +----+ > > | FA | | AAAF | | AAAH | | HA | > > +----+ +------+ +------+ +----+ > > <--------------------- ---------------------> > > STA, Session-Id = foo STA, Session-Id = bar > > Figure 3: Session Termination and Session Identifiers " > > > > > > > > > > > However, since the issue is a real one, it must be solved somehow. The > > > following is my proposal. > > > > > > 1) In the MIP draft, we should require that the HAR has the same > > > Session-Id as the AMR that caused it to be generated. As a result of > > > this protocol change, > > > > This was discussed about a year a go and identified that the Session-Id for the > > AMR and the HAR MUST be different. What you are raising here is an old issue, so > > I really don't see why we should go here again. > > > > Furthermore, the functionality that you mention in bullet 1 and 2 are already > > fulfilled today, with help of the Acct-Multi-Session-Id, see e.g. section 1.3 > > Support for Mobile IP Handoffs: > > > > "... > > Since the AAAH may be session-stateless, it is necessary for the > > resulting HAR received by the HA to be identified as a continuation > > of an existing session. If the HA receives an HAR for a mobile node, > > with a new session identifier, and the HA can guarantee that this > > request is to extend service for an existing service, then the HA > > MUST be able to modify its internal session state information to > > reflect the new session identifier. > > > > It is necessary for accounting records to have some commonality > > across handoffs in order for correlation to occur. Therefore, the > > home agent MUST send the same Acct-Multi-Session-Id AVP value in all > > HAAs for the mobile's session. That is, the HA generates a unique > > Acct-Multi-Session-Id when receiving an HAR for a new session, and > > returns this same value in every HAA for the session. This Acct- > > Multi-Session-Id AVP will be returned to the foreign agent by the > > AAAH in the AMA. Both the foreign and home agents MUST include the > > Acct-Multi-Session-Id in the accounting messages. > > > > ACR, Session-Id = foo ACR, Session-Id = bar > > Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a > > ---------------------> <-------------------- > > +----+ +------+ +------+ +----+ > > | FA | | AAAF | | AAAH | | HA | > > +----+ +------+ +------+ +----+ > > <--------------------- ---------------------> > > ACA, Session-Id = foo ACA, Session-Id = bar > > > > Figure 4: Accounting messages w/ Mobile IP Application > > ..." > > > > So, the HARs session-Id may change, but the acct-multi-session-id stays the same > > for both the HA and FAs. You can also look at issue Issue 290: Handling of > > Acct-Multi-Session-Id AVP, which was discussed and solved in February. > > > > Again, the draft has already this functionality (by the Acct-Multi-Session-Id > > AV.), so MHO I really don't see why we should discuss this any further, and most > > likely postpone the time line for this draft even further. > > > > /Tony > > > > > > > > > > > a) the session scope seen by the HA will match the session scope > > > seen by the FAs, the AAAFs, and the AAAHs, > > > > > > b) the AAAH does not need to be session-stateful, and > > > > > > c) it makes no difference whether all the HARs are issued by the > > > same AAAH or not. > > > > > > This change also allows us to remove the following nonsensical > > > statements from section 1.2 of the MIP draft: > > > > > > If the AAAH is session-stateful, it MUST send the same session > > > identifier for all HARs initiated on behalf of a given mobile > > > node's session. Otherwise, if the AAAH is session-stateless, it > > > will manufacture a unique session-id for every HAR. > > > > > > The nonsense consists of making a protocol requirement conditional on > > > an implementation decision (if session-stateful, then MUST send same > > > Session-Id). And of what use is the MUST if the HA can't depend on > > > it? > > > > > > 2) When an HA receives an HAR for a given multi-session that has a > > > different Session-Id from previous HARs for the same multi-session, > > > the HA MUST generate an ACR with an Accounting-Record-Type of > > > STOP_RECORD containing the old Session-Id followed by an ACR with an > > > Accounting-Record-Type of START_RECORD containing the new Session-Id. > > > > > > As a result of this protocol change, > > > > > > a) HA accounting sessions will have the same scope as FA > > > accounting sessions so that the records could be matched by an > > > accounting server if desired, and > > > > > > b) FA and HA accounting records will contain the same Session-Id > > > to facilitate such matching as well as to facilitate auditing. > > > > > > David S. > > > > > > john.loughney@nokia.com wrote: > > > > > > > > Hi all, > > > > > > > > I have made the changes, so issue 336 is closed. > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Loughney John (NRC/Helsinki) > > > > > Sent: 02 May, 2002 10:32 > > > > > To: johanj@ipunplugged.com; aaa-wg@merit.edu > > > > > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and > > > > > accounting sessions > > > > > > > > > > > > > > > Hi Johan, > > > > > > > > > > > Requested change: > > > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is > > > > > globally unique (see > > > > > > section 8.8), is used during the authorization phase to > > > > > identify a > > > > > > particular session. Services that do not require any > > > > > authorization > > > > > > still use the Session-Id AVP to identify sessions. > > > > > > > > > > > > to > > > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is globally > > > > > unique (see > > > > > > section 8.8), is used during the authorization phase to identify a > > > > > > particular session. Services that do not require any authorization > > > > > > still use the Session-Id AVP to identify sessions. > > > > > Accounting messages > > > > > > MUST use a different Session-Id from that sent in > > > > > > authorization messages. > > > > > > > > > > Somehow, the "MUST use" part of the last sentence worries me. I think > > > > > that it may be more application specific. I'd prefer to > > > > > state something > > > > > more like: > > > > > > > > > > Accounting messages MAY use a different Session-Id from > > > > > that sent in > > > > > authorization messages. Specific applications MAY require different > > > > > a Session-ID for accounting messages. > > > > > > > > > > Then, the application (for example MIP) could use a MUST. > > > > > > > > > > Comments? > > > > > John > > > > > > > > > > > > > > > > -- > > > David Spence email: DSpence@Interlinknetworks.com > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > Ann Arbor, MI 48108 > > > U.S.A. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Tue Jun 4 14:59: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 OAA10683 for ; Tue, 4 Jun 2002 14:59:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80B5A9122D; Tue, 4 Jun 2002 14:59:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5493191233; Tue, 4 Jun 2002 14:59:50 -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 64D9C9122D for ; Tue, 4 Jun 2002 14:59:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F29A85DEC5; Tue, 4 Jun 2002 14:59:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DC6DB5DE82 for ; Tue, 4 Jun 2002 14:59:43 -0400 (EDT) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 40A126C; Tue, 4 Jun 2002 14:59:51 -0400 (EDT) Message-ID: <3CFD0E6B.67B5D24E@Interlinknetworks.com> Date: Tue, 04 Jun 2002 15:00:59 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: > > Hi David, > > David Spence wrote: > > > Tony, > > > > I am aware of the function of the Acct-Multi-Session-Id, and you are correct > > that it binds the sessions of the multi-session together. What I was trying to > > do was to preserve Diameter's notion of a session and salvage the function of a > > Session-Id, which ought to bind the messages within a session together and ought > > to be useful for purposes such as auditing, independent of application. > > Session-Id should not work differently for MIP than it does for other Diameter > > applications. > > Well, MIP is very different then NASREQ, since you do have to deal with the fact that > the MN moves between different FAs, but stays anchored in the same HA in MIP. So, to > be able to use Base functionality such as STR/STA, the Session-id is split between the > FA and AAAH, and the HA and AAAH. This was decided over a year ago. Yes. I see now that the HA Session-Id needs to be different than the FA Session-Id. > > > Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. > > The Acct-Multi-Session-Id AVP is not included in every MIP message. > > Yes it is! The Acct-Multi-Session-Id is always sent in HAA and AMA, see my previous > text below. However, the ABNF in MIP-10 for HAA and AMA is wrong, should be {} and not > []. I will fix that in -11. No it isn't! The Acct-Multi-Session-Id is not always included in the HAR and AMR, but the Session-Id is. My statement is correct. By the way, if the Acct-Multi-Session-Id is always included in the AMA as you claim, then your Command-Code table in section 8.1 is in error: +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 1 | > > /Tony > > > The > > Session-Id AVP is. > > > > You are correct that my proposal failed to address the termination of the > > individual authorization sessions. Unfortunately, MIP, as it is, is simply > > broken. Not only don't HA sessions correspond to FA sessions. In mobileip-10, > > they also have no identifier that appears in every message of the session. And > > there is no mechanism to identify sessions between the HA and the various AAAH's > > that may be involved. I believe MIP is a faulty extension of Diameter if HA > > sessions cannot be identified using the base protocol. > > > > > Therefore, I'm afraid issue 336 is still unresolved, and now we have a new issue > > regarding the brokeness of HA sessions. That's more than I want to try to fix > > tonight so, in the words of Scarlett O'Hara, I'll worry about that tomorrow. > > > > Dave > > > > Tony Johansson wrote: > > > > > > Hi David, > > > > > > David Spence wrote: > > > > > > > I've had my head buried in NASREQ too long. I let this one slide by > > > > without picking up on it. Johan has identified a real problem in issue > > > > 336, but I believe he has proposed the wrong solution to it. There is a > > > > very important reason why the accounting Session-Id should be the same as > > > > the authorization Session-Id. It's to facilitate auditing. It ought to > > > > be possible to verify in an audit that sessions accounted for were, in > > > > fact, authorized. Including the same Session-Id in authorization and > > > > accounting messages has been a key concept of Diameter since the > > > > beginning. We should not even propose changing something this basic > > > > this late in the process. But in this case, we really can't. The > > > > Session-Id MUST be the same for both the authorization and accounting > > > > messages. > > > > > > Since the nature of MIP is that you move between FAs and as stated in the MIP > > > draft: > > > > > > " > > > .... > > > A mobile node's session is identified via its identity in the User- > > > Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address > > > AVPs. This is necessary in order to allow the session state machine, > > > defined in the base protocol [DIAMBASE], to be used unmodified with > > > this application. Therefore, an STR from a foreign agent would free > > > the session from the foreign agent, but not the one towards the home > > > agent (see figure 3). > > > > > > STR, Session-Id = foo STR, Session-Id = bar > > > ---------------------> <-------------------- > > > +----+ +------+ +------+ +----+ > > > | FA | | AAAF | | AAAH | | HA | > > > +----+ +------+ +------+ +----+ > > > <--------------------- ---------------------> > > > STA, Session-Id = foo STA, Session-Id = bar > > > Figure 3: Session Termination and Session Identifiers " > > > > > > > > > > > > > > > However, since the issue is a real one, it must be solved somehow. The > > > > following is my proposal. > > > > > > > > 1) In the MIP draft, we should require that the HAR has the same > > > > Session-Id as the AMR that caused it to be generated. As a result of > > > > this protocol change, > > > > > > This was discussed about a year a go and identified that the Session-Id for the > > > AMR and the HAR MUST be different. What you are raising here is an old issue, so > > > I really don't see why we should go here again. > > > > > > Furthermore, the functionality that you mention in bullet 1 and 2 are already > > > fulfilled today, with help of the Acct-Multi-Session-Id, see e.g. section 1.3 > > > Support for Mobile IP Handoffs: > > > > > > "... > > > Since the AAAH may be session-stateless, it is necessary for the > > > resulting HAR received by the HA to be identified as a continuation > > > of an existing session. If the HA receives an HAR for a mobile node, > > > with a new session identifier, and the HA can guarantee that this > > > request is to extend service for an existing service, then the HA > > > MUST be able to modify its internal session state information to > > > reflect the new session identifier. > > > > > > It is necessary for accounting records to have some commonality > > > across handoffs in order for correlation to occur. Therefore, the > > > home agent MUST send the same Acct-Multi-Session-Id AVP value in all > > > HAAs for the mobile's session. That is, the HA generates a unique > > > Acct-Multi-Session-Id when receiving an HAR for a new session, and > > > returns this same value in every HAA for the session. This Acct- > > > Multi-Session-Id AVP will be returned to the foreign agent by the > > > AAAH in the AMA. Both the foreign and home agents MUST include the > > > Acct-Multi-Session-Id in the accounting messages. > > > > > > ACR, Session-Id = foo ACR, Session-Id = bar > > > Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a > > > ---------------------> <-------------------- > > > +----+ +------+ +------+ +----+ > > > | FA | | AAAF | | AAAH | | HA | > > > +----+ +------+ +------+ +----+ > > > <--------------------- ---------------------> > > > ACA, Session-Id = foo ACA, Session-Id = bar > > > > > > Figure 4: Accounting messages w/ Mobile IP Application > > > ..." > > > > > > So, the HARs session-Id may change, but the acct-multi-session-id stays the same > > > for both the HA and FAs. You can also look at issue Issue 290: Handling of > > > Acct-Multi-Session-Id AVP, which was discussed and solved in February. > > > > > > Again, the draft has already this functionality (by the Acct-Multi-Session-Id > > > AV.), so MHO I really don't see why we should discuss this any further, and most > > > likely postpone the time line for this draft even further. > > > > > > /Tony > > > > > > > > > > > > > > > a) the session scope seen by the HA will match the session scope > > > > seen by the FAs, the AAAFs, and the AAAHs, > > > > > > > > b) the AAAH does not need to be session-stateful, and > > > > > > > > c) it makes no difference whether all the HARs are issued by the > > > > same AAAH or not. > > > > > > > > This change also allows us to remove the following nonsensical > > > > statements from section 1.2 of the MIP draft: > > > > > > > > If the AAAH is session-stateful, it MUST send the same session > > > > identifier for all HARs initiated on behalf of a given mobile > > > > node's session. Otherwise, if the AAAH is session-stateless, it > > > > will manufacture a unique session-id for every HAR. > > > > > > > > The nonsense consists of making a protocol requirement conditional on > > > > an implementation decision (if session-stateful, then MUST send same > > > > Session-Id). And of what use is the MUST if the HA can't depend on > > > > it? > > > > > > > > 2) When an HA receives an HAR for a given multi-session that has a > > > > different Session-Id from previous HARs for the same multi-session, > > > > the HA MUST generate an ACR with an Accounting-Record-Type of > > > > STOP_RECORD containing the old Session-Id followed by an ACR with an > > > > Accounting-Record-Type of START_RECORD containing the new Session-Id. > > > > > > > > As a result of this protocol change, > > > > > > > > a) HA accounting sessions will have the same scope as FA > > > > accounting sessions so that the records could be matched by an > > > > accounting server if desired, and > > > > > > > > b) FA and HA accounting records will contain the same Session-Id > > > > to facilitate such matching as well as to facilitate auditing. > > > > > > > > David S. > > > > > > > > john.loughney@nokia.com wrote: > > > > > > > > > > Hi all, > > > > > > > > > > I have made the changes, so issue 336 is closed. > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Loughney John (NRC/Helsinki) > > > > > > Sent: 02 May, 2002 10:32 > > > > > > To: johanj@ipunplugged.com; aaa-wg@merit.edu > > > > > > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and > > > > > > accounting sessions > > > > > > > > > > > > > > > > > > Hi Johan, > > > > > > > > > > > > > Requested change: > > > > > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is > > > > > > globally unique (see > > > > > > > section 8.8), is used during the authorization phase to > > > > > > identify a > > > > > > > particular session. Services that do not require any > > > > > > authorization > > > > > > > still use the Session-Id AVP to identify sessions. > > > > > > > > > > > > > > to > > > > > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is globally > > > > > > unique (see > > > > > > > section 8.8), is used during the authorization phase to identify a > > > > > > > particular session. Services that do not require any authorization > > > > > > > still use the Session-Id AVP to identify sessions. > > > > > > Accounting messages > > > > > > > MUST use a different Session-Id from that sent in > > > > > > > authorization messages. > > > > > > > > > > > > Somehow, the "MUST use" part of the last sentence worries me. I think > > > > > > that it may be more application specific. I'd prefer to > > > > > > state something > > > > > > more like: > > > > > > > > > > > > Accounting messages MAY use a different Session-Id from > > > > > > that sent in > > > > > > authorization messages. Specific applications MAY require different > > > > > > a Session-ID for accounting messages. > > > > > > > > > > > > Then, the application (for example MIP) could use a MUST. > > > > > > > > > > > > Comments? > > > > > > John > > > > > > > > > > > > > > > > > > > > -- > > > > David Spence email: DSpence@Interlinknetworks.com > > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > > Ann Arbor, MI 48108 > > > > U.S.A. > > > > -- > > David Spence email: DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: +1 734 821 1203 > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > Ann Arbor, MI 48108 > > U.S.A. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Tue Jun 4 17:57: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 RAA17359 for ; Tue, 4 Jun 2002 17:57:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26A269121A; Tue, 4 Jun 2002 17:57:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECB4091252; Tue, 4 Jun 2002 17:57: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 CC2F49121A for ; Tue, 4 Jun 2002 17:57:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D82A5DDD1; Tue, 4 Jun 2002 17:57:27 -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 1B34D5DD90 for ; Tue, 4 Jun 2002 17:57:27 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g54LvYi08572; Tue, 4 Jun 2002 16:57:34 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g54LvXk25581; Tue, 4 Jun 2002 16:57:33 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA00370; Tue, 4 Jun 2002 16:57:33 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA17214; Tue, 4 Jun 2002 16:57:32 -0500 (CDT) Message-ID: <3CFD36E9.16743375@ericsson.com> Date: Tue, 04 Jun 2002 14:53:45 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, David Spence wrote: > Tony Johansson wrote: > > > > Hi David, > > > > David Spence wrote: > > > > > Tony, > > > > > > I am aware of the function of the Acct-Multi-Session-Id, and you are correct > > > that it binds the sessions of the multi-session together. What I was trying to > > > do was to preserve Diameter's notion of a session and salvage the function of a > > > Session-Id, which ought to bind the messages within a session together and ought > > > to be useful for purposes such as auditing, independent of application. > > > Session-Id should not work differently for MIP than it does for other Diameter > > > applications. > > > > Well, MIP is very different then NASREQ, since you do have to deal with the fact that > > the MN moves between different FAs, but stays anchored in the same HA in MIP. So, to > > be able to use Base functionality such as STR/STA, the Session-id is split between the > > FA and AAAH, and the HA and AAAH. This was decided over a year ago. > > Yes. I see now that the HA Session-Id needs to be different than the FA > Session-Id. Good that we agree. > > > > > > > Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. > > > The Acct-Multi-Session-Id AVP is not included in every MIP message. > > > > Yes it is! The Acct-Multi-Session-Id is always sent in HAA and AMA, see my previous > > text below. However, the ABNF in MIP-10 for HAA and AMA is wrong, should be {} and not > > []. I will fix that in -11. > > No it isn't! The Acct-Multi-Session-Id is not always included in the HAR and > AMR, but the Session-Id is. My statement is correct. I'm lost?! The Acct-Multi-Session-Id is used to make sure that we can synchronize the ACR/ACA from the FAs and the HA. So, why would you need the Acct-Multi-Session-Id in the HAR and AMR? > > > By the way, if the Acct-Multi-Session-Id is always included in the AMA as you > claim, then your Command-Code table in section 8.1 is in error: > > +-----------------------+ > | Command-Code | > |-----+-----+-----+-----+ > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 1 | Good catch. Fixed in -11. Thanks, /Tony > > > > > > /Tony > > > > > The > > > Session-Id AVP is. > > > > > > You are correct that my proposal failed to address the termination of the > > > individual authorization sessions. Unfortunately, MIP, as it is, is simply > > > broken. Not only don't HA sessions correspond to FA sessions. In mobileip-10, > > > they also have no identifier that appears in every message of the session. And > > > there is no mechanism to identify sessions between the HA and the various AAAH's > > > that may be involved. I believe MIP is a faulty extension of Diameter if HA > > > sessions cannot be identified using the base protocol. > > > > > > > > Therefore, I'm afraid issue 336 is still unresolved, and now we have a new issue > > > regarding the brokeness of HA sessions. That's more than I want to try to fix > > > tonight so, in the words of Scarlett O'Hara, I'll worry about that tomorrow. > > > > > > Dave > > > > > > Tony Johansson wrote: > > > > > > > > Hi David, > > > > > > > > David Spence wrote: > > > > > > > > > I've had my head buried in NASREQ too long. I let this one slide by > > > > > without picking up on it. Johan has identified a real problem in issue > > > > > 336, but I believe he has proposed the wrong solution to it. There is a > > > > > very important reason why the accounting Session-Id should be the same as > > > > > the authorization Session-Id. It's to facilitate auditing. It ought to > > > > > be possible to verify in an audit that sessions accounted for were, in > > > > > fact, authorized. Including the same Session-Id in authorization and > > > > > accounting messages has been a key concept of Diameter since the > > > > > beginning. We should not even propose changing something this basic > > > > > this late in the process. But in this case, we really can't. The > > > > > Session-Id MUST be the same for both the authorization and accounting > > > > > messages. > > > > > > > > Since the nature of MIP is that you move between FAs and as stated in the MIP > > > > draft: > > > > > > > > " > > > > .... > > > > A mobile node's session is identified via its identity in the User- > > > > Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address > > > > AVPs. This is necessary in order to allow the session state machine, > > > > defined in the base protocol [DIAMBASE], to be used unmodified with > > > > this application. Therefore, an STR from a foreign agent would free > > > > the session from the foreign agent, but not the one towards the home > > > > agent (see figure 3). > > > > > > > > STR, Session-Id = foo STR, Session-Id = bar > > > > ---------------------> <-------------------- > > > > +----+ +------+ +------+ +----+ > > > > | FA | | AAAF | | AAAH | | HA | > > > > +----+ +------+ +------+ +----+ > > > > <--------------------- ---------------------> > > > > STA, Session-Id = foo STA, Session-Id = bar > > > > Figure 3: Session Termination and Session Identifiers " > > > > > > > > > > > > > > > > > > > However, since the issue is a real one, it must be solved somehow. The > > > > > following is my proposal. > > > > > > > > > > 1) In the MIP draft, we should require that the HAR has the same > > > > > Session-Id as the AMR that caused it to be generated. As a result of > > > > > this protocol change, > > > > > > > > This was discussed about a year a go and identified that the Session-Id for the > > > > AMR and the HAR MUST be different. What you are raising here is an old issue, so > > > > I really don't see why we should go here again. > > > > > > > > Furthermore, the functionality that you mention in bullet 1 and 2 are already > > > > fulfilled today, with help of the Acct-Multi-Session-Id, see e.g. section 1.3 > > > > Support for Mobile IP Handoffs: > > > > > > > > "... > > > > Since the AAAH may be session-stateless, it is necessary for the > > > > resulting HAR received by the HA to be identified as a continuation > > > > of an existing session. If the HA receives an HAR for a mobile node, > > > > with a new session identifier, and the HA can guarantee that this > > > > request is to extend service for an existing service, then the HA > > > > MUST be able to modify its internal session state information to > > > > reflect the new session identifier. > > > > > > > > It is necessary for accounting records to have some commonality > > > > across handoffs in order for correlation to occur. Therefore, the > > > > home agent MUST send the same Acct-Multi-Session-Id AVP value in all > > > > HAAs for the mobile's session. That is, the HA generates a unique > > > > Acct-Multi-Session-Id when receiving an HAR for a new session, and > > > > returns this same value in every HAA for the session. This Acct- > > > > Multi-Session-Id AVP will be returned to the foreign agent by the > > > > AAAH in the AMA. Both the foreign and home agents MUST include the > > > > Acct-Multi-Session-Id in the accounting messages. > > > > > > > > ACR, Session-Id = foo ACR, Session-Id = bar > > > > Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a > > > > ---------------------> <-------------------- > > > > +----+ +------+ +------+ +----+ > > > > | FA | | AAAF | | AAAH | | HA | > > > > +----+ +------+ +------+ +----+ > > > > <--------------------- ---------------------> > > > > ACA, Session-Id = foo ACA, Session-Id = bar > > > > > > > > Figure 4: Accounting messages w/ Mobile IP Application > > > > ..." > > > > > > > > So, the HARs session-Id may change, but the acct-multi-session-id stays the same > > > > for both the HA and FAs. You can also look at issue Issue 290: Handling of > > > > Acct-Multi-Session-Id AVP, which was discussed and solved in February. > > > > > > > > Again, the draft has already this functionality (by the Acct-Multi-Session-Id > > > > AV.), so MHO I really don't see why we should discuss this any further, and most > > > > likely postpone the time line for this draft even further. > > > > > > > > /Tony > > > > > > > > > > > > > > > > > > > a) the session scope seen by the HA will match the session scope > > > > > seen by the FAs, the AAAFs, and the AAAHs, > > > > > > > > > > b) the AAAH does not need to be session-stateful, and > > > > > > > > > > c) it makes no difference whether all the HARs are issued by the > > > > > same AAAH or not. > > > > > > > > > > This change also allows us to remove the following nonsensical > > > > > statements from section 1.2 of the MIP draft: > > > > > > > > > > If the AAAH is session-stateful, it MUST send the same session > > > > > identifier for all HARs initiated on behalf of a given mobile > > > > > node's session. Otherwise, if the AAAH is session-stateless, it > > > > > will manufacture a unique session-id for every HAR. > > > > > > > > > > The nonsense consists of making a protocol requirement conditional on > > > > > an implementation decision (if session-stateful, then MUST send same > > > > > Session-Id). And of what use is the MUST if the HA can't depend on > > > > > it? > > > > > > > > > > 2) When an HA receives an HAR for a given multi-session that has a > > > > > different Session-Id from previous HARs for the same multi-session, > > > > > the HA MUST generate an ACR with an Accounting-Record-Type of > > > > > STOP_RECORD containing the old Session-Id followed by an ACR with an > > > > > Accounting-Record-Type of START_RECORD containing the new Session-Id. > > > > > > > > > > As a result of this protocol change, > > > > > > > > > > a) HA accounting sessions will have the same scope as FA > > > > > accounting sessions so that the records could be matched by an > > > > > accounting server if desired, and > > > > > > > > > > b) FA and HA accounting records will contain the same Session-Id > > > > > to facilitate such matching as well as to facilitate auditing. > > > > > > > > > > David S. > > > > > > > > > > john.loughney@nokia.com wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I have made the changes, so issue 336 is closed. > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Loughney John (NRC/Helsinki) > > > > > > > Sent: 02 May, 2002 10:32 > > > > > > > To: johanj@ipunplugged.com; aaa-wg@merit.edu > > > > > > > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and > > > > > > > accounting sessions > > > > > > > > > > > > > > > > > > > > > Hi Johan, > > > > > > > > > > > > > > > Requested change: > > > > > > > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is > > > > > > > globally unique (see > > > > > > > > section 8.8), is used during the authorization phase to > > > > > > > identify a > > > > > > > > particular session. Services that do not require any > > > > > > > authorization > > > > > > > > still use the Session-Id AVP to identify sessions. > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > The Diameter protocol's Session-Id AVP, which is globally > > > > > > > unique (see > > > > > > > > section 8.8), is used during the authorization phase to identify a > > > > > > > > particular session. Services that do not require any authorization > > > > > > > > still use the Session-Id AVP to identify sessions. > > > > > > > Accounting messages > > > > > > > > MUST use a different Session-Id from that sent in > > > > > > > > authorization messages. > > > > > > > > > > > > > > Somehow, the "MUST use" part of the last sentence worries me. I think > > > > > > > that it may be more application specific. I'd prefer to > > > > > > > state something > > > > > > > more like: > > > > > > > > > > > > > > Accounting messages MAY use a different Session-Id from > > > > > > > that sent in > > > > > > > authorization messages. Specific applications MAY require different > > > > > > > a Session-ID for accounting messages. > > > > > > > > > > > > > > Then, the application (for example MIP) could use a MUST. > > > > > > > > > > > > > > Comments? > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > David Spence email: DSpence@Interlinknetworks.com > > > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > > > Ann Arbor, MI 48108 > > > > > U.S.A. > > > > > > -- > > > David Spence email: DSpence@Interlinknetworks.com > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > Ann Arbor, MI 48108 > > > U.S.A. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Tue Jun 4 18:07: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 SAA17537 for ; Tue, 4 Jun 2002 18:07:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3AAFF91252; Tue, 4 Jun 2002 18:07:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0650591253; Tue, 4 Jun 2002 18:07: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 0882091252 for ; Tue, 4 Jun 2002 18:07:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C2135DDC9; Tue, 4 Jun 2002 18:07:09 -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 03DEC5DD90 for ; Tue, 4 Jun 2002 18:07:09 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020604220715.CJDM16290.fep02-svc.swip.net@ipunplugged.com>; Wed, 5 Jun 2002 00:07:15 +0200 Message-ID: <3CFD3A8B.6010709@ipunplugged.com> Date: Wed, 05 Jun 2002 00:09:15 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Spence Cc: Tony Johansson , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.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 David Spence wrote: >>>Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. >>>The Acct-Multi-Session-Id AVP is not included in every MIP message. >>> >>> >>Yes it is! The Acct-Multi-Session-Id is always sent in HAA and AMA, see my previous >>text below. However, the ABNF in MIP-10 for HAA and AMA is wrong, should be {} and not >>[]. I will fix that in -11. >> >> > >No it isn't! The Acct-Multi-Session-Id is not always included in the HAR and >AMR, but the Session-Id is. My statement is correct. > >By the way, if the Acct-Multi-Session-Id is always included in the AMA as you >claim, then your Command-Code table in section 8.1 is in error: > > +-----------------------+ > | Command-Code | > |-----+-----+-----+-----+ > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 1 | > Well, when Tony said that it was always included he didn't really mean always. An AMA that signals an error does not contain an Acct-Multi-Session-Id. Neither should the HAA I guess. It was noted at the Diameter Bakeoff last fall that messages with another result code than DIAMETER_SUCCESS rarely followed or could follow the ABNFs unless dummy AVPs were added. The resolution to this problem was to weaken the ABNFs. Personally I would have prefered ABNFs depending on the result code, but it was not the wish of the editor at the time. >>>>>I've had my head buried in NASREQ too long. I let this one slide by >>>>>without picking up on it. Johan has identified a real problem in issue >>>>>336, but I believe he has proposed the wrong solution to it. >>>>> Actually I didn't propose *a* solution but a number of them. My main wish was that the conceptual relationship between the authorization session and the accounting session would be resolved. This was not fulfilled by the accepted solution and I wonder what parts of the text make what assumptions in this regard as well as in a few others. It would have been good in my opinion if more care had been taken to define the basic concepts involved in the protocol as well as more willingness to discuss them among a broader selection of the workgroup members. But the world is imperfect and I expect the first interop after the drafts becomes rfcs to be very interesting and very educational. j From owner-aaa-wg@merit.edu Tue Jun 4 18:37: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 SAA17983 for ; Tue, 4 Jun 2002 18:37:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90C6C91255; Tue, 4 Jun 2002 18:37:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 607DA91256; Tue, 4 Jun 2002 18:37: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 5269591255 for ; Tue, 4 Jun 2002 18:37:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB3685DDB9; Tue, 4 Jun 2002 18:37:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 257135DD90 for ; Tue, 4 Jun 2002 18:37:45 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep01-svc.swip.net with ESMTP id <20020604223751.CNKH24679.fep01-svc.swip.net@ipunplugged.com>; Wed, 5 Jun 2002 00:37:51 +0200 Message-ID: <3CFD41B8.2050707@ipunplugged.com> Date: Wed, 05 Jun 2002 00:39:52 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Johansson Cc: David Spence , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.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 Is this a lapsus or is it now ok to not follow the ABNF in some cases? j Tony Johansson wrote: >>By the way, if the Acct-Multi-Session-Id is always included in the AMA as you >>claim, then your Command-Code table in section 8.1 is in error: >> >> +-----------------------+ >> | Command-Code | >> |-----+-----+-----+-----+ >> Attribute Name | AMR | AMA | HAR | HAA | >> ------------------------------|-----+-----+-----+-----+ >> Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 1 | >> >> > >Good catch. Fixed in -11. > >Thanks, > >/Tony > > From owner-aaa-wg@merit.edu Tue Jun 4 19:08:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19628 for ; Tue, 4 Jun 2002 19:08:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49F9791257; Tue, 4 Jun 2002 19:08:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1999E91259; Tue, 4 Jun 2002 19:08: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 ED73991257 for ; Tue, 4 Jun 2002 19:08:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 826205DDC9; Tue, 4 Jun 2002 19:08:32 -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 4A52F5DDB9 for ; Tue, 4 Jun 2002 19:08:32 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g54N8di00904; Tue, 4 Jun 2002 18:08:39 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g54N8ck08092; Tue, 4 Jun 2002 18:08:38 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA02979; Tue, 4 Jun 2002 18:08:38 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA18236; Tue, 4 Jun 2002 18:08:37 -0500 (CDT) Message-ID: <3CFD4792.C766067A@ericsson.com> Date: Tue, 04 Jun 2002 16:04:50 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: David Spence , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accountingsessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.com> <3CFD41B8.2050707@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, I guess I was way to quick to answer David here :( Here is how I believe it should be: The Acct-Multi-Session-Id AVP MUST be added in the HAA and AMA as stated in section 1.2 and 1.3. However, since both AMA and HAA are answers the Acct-Session-Id AVP should therefore be set as optional in the ABNF (since an error could occur, with the consequence that no Acct-Multi-Session-Id could be sent back....). So, in ABNF for AMA and HAA: [ Acct-Multi-Session-Id ] and table in section 8.1 should be: +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Acct-Multi-Session-Id | 0 | 0-1 | 0 | 0-1 | /Tony Johan Johansson wrote: > Is this a lapsus or is it now ok to not follow the ABNF in some cases? > > j > > Tony Johansson wrote: > > >>By the way, if the Acct-Multi-Session-Id is always included in the AMA as you > >>claim, then your Command-Code table in section 8.1 is in error: > >> > >> +-----------------------+ > >> | Command-Code | > >> |-----+-----+-----+-----+ > >> Attribute Name | AMR | AMA | HAR | HAA | > >> ------------------------------|-----+-----+-----+-----+ > >> Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 1 | > >> > >> > > > >Good catch. Fixed in -11. > > > >Thanks, > > > >/Tony > > > > From owner-aaa-wg@merit.edu Wed Jun 5 16:13: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 QAA16761 for ; Wed, 5 Jun 2002 16:13:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 505A591227; Wed, 5 Jun 2002 16:13:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C19291253; Wed, 5 Jun 2002 16:13: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 2859891227 for ; Wed, 5 Jun 2002 16:13:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF88E5DE96; Wed, 5 Jun 2002 16:13:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BE4015DE31 for ; Wed, 5 Jun 2002 16:13:27 -0400 (EDT) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 701FF6C; Wed, 5 Jun 2002 16:13:35 -0400 (EDT) Message-ID: <3CFE7134.DAD3DC77@Interlinknetworks.com> Date: Wed, 05 Jun 2002 16:14:44 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Without attempting to go through all the scenarios or draft all the text to be added to mobileip-10, here is my proposal for how to resolve issue 336 (Clarify relationship between auth and accounting sessions) in a good way. These are my goals: 1. Create a one-to-one correspondence between FA sessions and HA sessions so that for each FA session there will be a single HA session for the same MN that starts and ends at approximately the same time as the FA session it corresponds to. 2. Diameter MobileIPv4 accounting sessions should exactly match the authorization sessions and have the same Session-Id. 3. Accounting servers should be able to match the FA accounting records to the HA accounting records for a given MN. 4. AAAH Diameter Servers need not be session stateful. The protocol should work the same way whether Diameter Servers are session stateful or not. 5. A domain should be able to have more than one Diameter Server fulfilling the AAAH role. The following are the general principles governing HA sessions. The first two principles exist today. I am merely restating them to emphasize that I am not changing them. 1. An HA session begins when a Diameter Server sends an HAR command to an HA and receives an HAA command in response. 2. An HA session should normally end when an HA sends an STR command to a Diameter Server and receives an STA command in response. Discussion: When an AAAH receives an STR command from an AAAF for an FA session, it does not attempt to terminate the corresponding HA session by sending an ASR command. The HA will find out via the Mobile IP protocol that the session has ended and will send and STR to the AAAH. It is important to maintain this principle because the AAAH may not be aware of a pending handoff. If the HA were to terminate a session before commencing a new session for the pending handoff, the multi-session would terminate and the handoff would then fail. 3. When an AAAH receives an AMR command that represents a new FA session -- whether for a new multi-session or for a handoff within an existing multi-session -- it generates an HAR command with a new Session-Id. 4. When an HA receives an HAR command for a new session within a multi-session, it generates an HAA in response and also generates an ACR command with Accounting-Record-Type of START_RECORD. 5. When an HA terminates a session within a multi-session, it generates an STR command and also generates an ACR command with Accounting-Record-Type of STOP_RECORD. Principle number 3, above, cannot be implemented without a slight protocol change. First of all, I don't know that there is any way that a non-stateful AAAH can distinguish an AMR for a new session from a reauth AMR for an existing session. Furthermore, for a reauth, the AAAH must include the Session-Id in the HAR that identifies the reauthenticated/reauthorized session. If the AAAH is stateless, it has no way of knowing what Session-Id to use. Similarly if the AMR for the reauth is sent to a different AAAH, the second AAAH will not know what Session-Id to use in the HAR. In both of these cases, this problem is currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER PROTOCOL. In both of these cases, the AAAH generates a new value for the Session-Id. The HA cannot rely on the Session-Id in a reauth HAR to identify the session being reauthenticated/reauthorized. It must find the session some other way. In order to fix the Diameter-MobileIPv4 protocol so that it works correctly, I propose to define two new AVPs: FA-Session-Id This AVP is inserted in HAR commands by the AAAH to indicate the Session-Id of the corresponding FA session. It is inserted in ACR commands along with the MIP-Foreign-Agent-Host AVP by the HA to identify the corresponding FA session to the accounting server. HA-Session-Id This AVP is inserted in AMA commands by the AAAH to indicate the Session-Id of the corresponding HA session. It is inserted in subsequent AMR commands for the same session by the FA. When generating a HAR command, if the corresponding AMR command contains an HA-Session-Id AVP, then the AAAH includes the value of the HA-Session-Id AVP in the Session-Id AVP it inserts in the HAR. Otherwise it generates a new value for the Session-Id it inserts in the HAR. The FA also inserts the HA-Session-Id AVP in ACR commands to identify the corresponding HA session to the accounting server. This proposal requires no changes to the base protocol except to remove the following stipulation that may have been added in an earlier attempt to resolve issue 336: Accounting messages MAY use a different Session-Id from that sent in authorization messages. Specific applications MAY require different a Session-ID for accounting messages. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Thu Jun 6 21:46:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24292 for ; Thu, 6 Jun 2002 21:46:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 869AD912E5; Thu, 6 Jun 2002 21:45:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57F5F912E6; Thu, 6 Jun 2002 21:45: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 3E18C912E5 for ; Thu, 6 Jun 2002 21:45:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 557AA5DE37; Thu, 6 Jun 2002 21:45:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by segue.merit.edu (Postfix) with ESMTP id 7E0C05DDA2 for ; Thu, 6 Jun 2002 21:45:40 -0400 (EDT) Received: from liuqb.cwc.nus.edu.sg ([172.16.2.39]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id JAA07575 for ; Fri, 7 Jun 2002 09:44:32 +0800 (SGT) Message-Id: <4.3.2.7.2.20020607094744.02521ea0@postman.cwc.nus.edu.sg> X-Sender: liuqb@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jun 2002 09:48:54 +0800 To: aaa-wg@merit.edu From: Liu Qiong Bo Subject: [AAA-WG]: msg length and avp length Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi. On page 45 of base 10, there is a figure to demonstration the grouped AVP example-avp. but I think example-avp's length (468) is wrong. 468!=19+50+51+223+137. in section 4.3, for Grouped AVP: "The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. Thus the AVP length field of an AVP of type Grouped is always a multiple of 4. " Hence can I believe: 1. the common avp's length doesn't include the padding's length, so it may be not a multiple of 4. 2. the grouped avp's length includes all the padding 's length, so it must be a multiple of 4. 3. how about a diameter message length? Does it include all the avp's length including the padding's length? Regards. Coral From owner-aaa-wg@merit.edu Fri Jun 7 08:49: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 IAA25043 for ; Fri, 7 Jun 2002 08:49:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D14B9912BE; Fri, 7 Jun 2002 08:49:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CC94912BF; Fri, 7 Jun 2002 08:49: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 A534B912BE for ; Fri, 7 Jun 2002 08:49:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D447B5DDFA; Fri, 7 Jun 2002 08:49: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 574075DDAA for ; Fri, 7 Jun 2002 08:49:50 -0400 (EDT) Received: (qmail 12323 invoked by uid 500); 7 Jun 2002 12:49:58 -0000 Date: Fri, 7 Jun 2002 07:49:58 -0500 From: David Frascone To: Liu Qiong Bo Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: msg length and avp length Message-ID: <20020607124957.GH3047@newman.frascone.com> Mail-Followup-To: Liu Qiong Bo , aaa-wg@merit.edu References: <4.3.2.7.2.20020607094744.02521ea0@postman.cwc.nus.edu.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20020607094744.02521ea0@postman.cwc.nus.edu.sg> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Let me try to explain this. A grouped avp's length is the sum of all of the padded AVP's length + the size of it's (The grouped AVP) header. The padding of the grouped avp is not taken into account. So, in the example, the sum should be: 8 HeaderLength (Would be 12 if vendor specific) 20 Origin-Host AVP (1 byte of padding) 52 Session-Id (2 bytes of padding) 52 Session-Id (1 bytes of padding) 224 Recovery-Policy (1 byte of padding) 140 Futuristic-Acct-Record (3 bytes of padding) 496 Total - Discrepency 28 bytes The second session id is 4 bytes too large, in the diagram. You can count 8 bytes of header, 15 bytes of data, and there are 32 bytes of data in omitted rows, giving a length of 55, not 51. The Futuristic Acct Record Header is also wrong. There are 8 bytes of header, and 9 bytes of data in the diagram, with 128 bytes of data in omitted rows, giving a length of 145, not 37. These errors are causing some of the confusion. I apologize in advance if I have messed up the math. It's awfly early :) -Dave On Friday, 07 Jun 2002, Liu Qiong Bo wrote: > Hi. > > On page 45 of base 10, there is a figure to demonstration the grouped AVP > example-avp. but I think example-avp's length (468) is wrong. > 468!=19+50+51+223+137. > > in section 4.3, for Grouped AVP: > "The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the > total length of all included AVPs, including their headers and padding. > Thus the AVP length field of an AVP of type Grouped is always a multiple of > 4. " > > Hence can I believe: > 1. the common avp's length doesn't include the padding's length, so it may > be not a multiple of 4. > > 2. the grouped avp's length includes all the padding 's length, so it must > be a multiple of 4. > > 3. how about a diameter message length? Does it include all the avp's > length including the padding's length? > > Regards. > > Coral > -- David Frascone Should I weed the lawn or say it's a garden? From owner-aaa-wg@merit.edu Fri Jun 7 17:14: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 RAA13160 for ; Fri, 7 Jun 2002 17:14:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F323A912D8; Fri, 7 Jun 2002 17:14:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA595912D9; Fri, 7 Jun 2002 17:14: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 DF65A912D8 for ; Fri, 7 Jun 2002 17:14:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31ED55DDD7; Fri, 7 Jun 2002 17:14:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 1BE635DDA4 for ; Fri, 7 Jun 2002 17:14:32 -0400 (EDT) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 42D197C for ; Fri, 7 Jun 2002 17:14:40 -0400 (EDT) Message-ID: <3D012285.15B9508A@Interlinknetworks.com> Date: Fri, 07 Jun 2002 17:15:49 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: Proposed resolution of Issue 295: More NASREQ AVPs needed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is my proposed resolution to issue 295, "More NASREQ AVPs needed". The original issue statement is a follows: Subject: [issue] More NASREQ AVPs needed Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: March 4, 2002 Reference: Document: NASREQ-09 Comment type: T Priority: S Section: various Rationale/Explanation of issue: There are a number of attributes defined in RADIUS RFCs that are needed for the correct operation of the Diameter NASREQ application. They are: CODE NAME RFC ---- ---- ---- 29 Termination-Action 2865 41 Acct-Delay-Time 2866 51 Acct-Link-Count 2866 55 Event-Timestamp 2869 78 Configuration-Token 2869 85 Acct-Interim-Interval 2869 87 NAS-Port-Id 2869 88 Framed-Pool 2869 95 NAS-IPv6-Address 3162 98 Login-IPv6-Host 3162 Note: These AVPs were not added to nasreq-09, so this issue requires more work in nasreq. Requested change: Add these attributes to nasreq as Diameter AVPs. Of the ten AVPs listed above, two of them, Event-Timestamp and Acct-Interim-Interval, have since been added to the base protocol. I only had to add references to them. The following is the proposed text for the other eight. I also expanded the definition of the State AVP to bring it into better conformance with RADIUS. The proposed text for it can be found below as well. This proposed text has been included in an interim version of the draft which can be downloaded from: http://ext.interlinknetworks.com/dspence/draft-ietf-aaa-diameter-nasreq-09-b.txt The following excerpts are the proposed text for issue 295. ========== +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Acct-Delay-Time 41 8.10 Unsigned32 | M | P | | V | Y | Acct-Link-Count 51 8.11 Unsigned32 | M | P | | V | Y | Configuration- 78 6.12 OctetString| M | | | P,V | | Token | | | | | | Framed-Pool 88 7.2.5.4 OctetString| M | P | | V | Y | Login-IPv6-Host 98 7.3.2 IPAddress | M | P | | V | Y | NAS-IPv6-Address 95 2.2.2 IPAddress | M | P | | V | Y | NAS-Port-Id 87 6.2 UTF8String | M | P | | V | Y | Termination- 29 6.13 Enumerated | M | P | | V | Y | Action | | | | | | ========== Message Format ::= < Diameter Header: 265, REQ, PXY > ... [ NAS-Port-Id ] [ NAS-IPv6-Address ] * [ Login-IPv6-Host ] ========== Message Format ::= < Diameter Header: 265, PXY > ... * [ Configuration-Token ] [ Acct-Interim-Interval ] [ Termination-Action ] [ Framed-Pool ] * [ Login-IPv6-Host ] ========== Message Format ::= < Diameter Header: 268, REQ, PXY > ... [ NAS-Port-Id ] [ NAS-IPv6-Address ] ========== Message Format ::= < Diameter Header: 268, PXY > ... * [ Configuration-Token ] [ Acct-Interim-Interval ] [ Termination-Action ] [ Framed-Pool ] ========== 2.2.2 NAS-IPv6-Address AVP The NAS-IPv6-Address AVP (AVP Code 95) [37] is of type IPAddress, and contains the IPv6 Address of the NAS providing service to the user. This AVP SHOULD only be added by a RADIUS/Diameter Translation Agent (see Section 9.0). When this AVP is present, the Origin-Host AVP identifies the RADIUS/Diameter Translation Agent rather than the NAS providing service to the user. ========== 2.2.4 State AVP The State AVP (AVP Code 24) [1] is of type OctetString and has two uses in the Diameter NASREQ application. The State AVP MAY be sent by a Diameter Server to a NAS in an AA- Response command that contains a Result-Code of DIAMETER_MULTI_ROUND_AUTH. If so, the NAS MUST return it unmodified in the subsquent AA-Request command. The State AVP MAY also be sent by a Diameter Server to a NAS in an AA-Response or Diameter-EAP-Response command that also includes a Termination-Action AVP with the value of AA-REQUEST. If the NAS performs the Termination-Action by sending a new AA-Request or Diameter-EAP-Request command upon termination of the current service, it MUST return the State AVP unmodified in the new request command. In either usage the NAS MUST NOT interpret the AVP locally. Usage of the State AVP is implementation dependent. ========== 6.2 NAS-Port-Id The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and identifies the port of the NAS which is authenticating the user. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-ID SHOULD be present in AA-Request and Diameter-EAP-Request commands if the NAS differentiates among its ports. NAS-Port-Id is intended for use by NASes which cannot conveniently number their ports. ========== 6.12 Configuration-Token AVP The Configuration-Token AVP (AVP Code 78) is of type OctetString and is sent by a Diameter Server to a Diameter Proxy Agent or Translation Agent in an AA-Answer or Diameter-EAP-Answer command to indicate a type of user profile to be used. It should not be sent to a Diameter Client (NAS). The format of the Data field of this AVP is site specific. ========== 6.13 Termination-Action AVP The Termination-Action AVP is of type Enumerated and indicates what action the NAS should take when the specified service is completed. This AVP SHOULD only be present in authorization responses. The following values are supported as listed in [33]: DEFAULT 0 Upon termination of the authorized service the NAS MUST terminate the current session. AA-REQUEST 1 Upon termination of the authorized service the NAS MAY send a new AA-Request (AAR) or Diameter-EAP-Request (DER) command. When the authorized service terminates, the NAS SHOULD NOT terminate the session or generate a Session-Termination-Request (STR) command. Instead, it SHOULD generate a new AAR or DER command which contains the same value of the Session-Id AVP it sent in the previous AAR or DER command. It SHOULD also include the State AVP from the previous AA-Answer (AAA) command or Diameter-EAP-Answer (DEA) command if it contained one. An exception to this rule applies, however, if the authorized service terminates due to the expiry of the Session-Timeout AVP. In this case, the NAS MUST terminate the expired session and MAY generate a new AAR or DER command with a new Session- Id. Note: The Termination-Action AVP is typically used for the login service (Service-Type = 1 or "Login") or by 802.1x access devices (e.g., NAS-Port-Type = 19 or "Wireless - IEEE 802.11"). When used for the login service, the service typically terminates when the login host clears the connection. The NAS may prompt the user for a new connection and issue a new AA-Request. When used by 802.1x access devices, the service typically terminates due to the expiry of the Session-Timeout AVP. The access device may then reauthenticate the user with a new AA-Request. The RECOMMENDED way to do this in Diameter is to use the Authorization-Lifetime AVP rather than the Termination-Action AVP. However, the Termination- Action AVP MAY be used when copied from a RADIUS Access-Accept to a Diameter AA-Answer by a Translation Agent. ========== 7.2.5.4 Framed-Pool AVP The Framed-Pool AVP (AVP Code 88) is of type OctetString and contains the name of an assigned address pool that SHOULD be used to assign an address for the user. If a NAS does not support multiple address pools, the NAS SHOULD ignore this AVP. Address pools are usually used for IP addresses, but can be used for other protocols if the NAS supports pools for those protocols. Although specified as type OctetString for compatibility with RADIUS [32], the encoding of the Data field SHOULD also conform to the rules for the UTF8String Data Format. ========== 7.3.2 Login-IPv6-Host AVP The Login-IPv6-Host AVP (AVP Code 98) [37] is of type IPAddress and contains the IPv6 address of a host with which to connect the user when the Login-Service AVP is included. It MAY be used in an AA- Request command as a hint to the Diameter Server that a specific host is desired, but the Diameter Server is not required to honor the hint in the AA-Answer. Two addresses have special significance: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF and 0. The value 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD allow the user to select an address. The value 0 indicates that the NAS SHOULD select a host to connect the user to. ========== 8.10 Acct-Delay-Time The Acct-Delay-Time AVP (AVP Code 41) is of type Unsigned32 and indicates the number of seconds during which the Diameter client has been trying to send the Accounting-Request (ACR) which contains it. The accounting server may subtract this value from the time the ACR arrives at the server to calculate the approximate time of the event that caused the ACR to be generated. This AVP is not used for retransmissions at the transport level (TCP or SCTP). Rather, it may be used when an ACR command cannot be transmitted because there is no appropriate peer to transmit it to or was rejected because it could not be delivered to its destination. In these cases, the command MAY be buffered and transmitted some time later when an appropriate peer-connection is available or after sufficient time has passed that the destination-host may be reachable and operational. If the ACR is resent in this way the Acct-Delay- Time AVP SHOULD be included. The value of this AVP indicates the number of seconds that elapsed between the time of the first attempt at transmission and the current attempt at transmission. ========== 8.11 Acct-Link-Count The Acct-Link-Count AVP (AVP Code 51) is of type Unsigned32 and indicates the number of links which are known to have been in a given multilink session at the time the accounting record is generated. This AVP MAY be included in Accounting-Requests for any session which may be part of a multilink service. The Acct-Link-Count AVP may be used to make it easier for an accounting server to know when it has all the records for a given multilink service. When the number of Accounting-Requests received with Accounting-Record-Type = STOP_RECORD and the same Acct-Multi- Session-Id and unique Session-Id's equals the largest value of Acct- Link-Count seen in those Accounting-Requests, all STOP_RECORD Accounting-Requests for that multilink service have been received. The following example showing eight Accounting-Requests illustrates how the Acct-Link-Count AVP is used. In the table below, only the relevant AVPs are shown although additional AVPs containing accounting information will also be present in the Accounting- Requests. Acct-Multi- Accounting- Acct- Session-Id Session-Id Record-Type Link-Count -------------------------------------------------------- "...10" "...10" START_RECORD 1 "...10" "...11" START_RECORD 2 "...10" "...11" STOP_RECORD 2 "...10" "...12" START_RECORD 3 "...10" "...13" START_RECORD 4 "...10" "...12" STOP_RECORD 4 "...10" "...13" STOP_RECORD 4 "...10" "...10" STOP_RECORD 4 ========== +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | AAR | AAA | DER | DEA | ------------------------------|-----+-----+-----+-----| Acct-Interim-Interval | 0 | 0-1 | 0 | 0-1 | Configuration-Token | 0 | 0+ | 0 | 0+ | Framed-Pool | 0 | 0-1 | 0 | 0-1 | Login-IPv6-Host | 0+ | 0+ | 0 | 0 | NAS-IPv6-Address | 0-1 | 0 | 0-1 | 0 | NAS-Port-Id | 0-1 | 0 | 0-1 | 0 | Termination-Action | 0 | 0-1 | 0 | 0-1 | ========== 10.2.1 Framed Access ... +-----------+ | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Acct-Delay-Time | 0-1 | 0-1 | Acct-Interim-Interval | 0-1 | 0-1 | Acct-Link-Count | 0-1 | 0-1 | Event-Timestamp | 0-1 | 0-1 | Framed-Pool | 0-1 | 0-1 | NAS-IPv6-Address | 0-1 | 0-1 | NAS-Port-Id | 0-1 | 0-1 | Termination-Action | 0-1 | 0-1 | ========== 10.2.2 Non-Framed Access ... +-----------+ | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Acct-Delay-Time | 0-1 | 0-1 | Acct-Interim-Interval | 0-1 | 0-1 | Event-Timestamp | 0-1 | 0-1 | Login-IPv6-Host | 0+ | 0+ | NAS-IPv6-Address | 0-1 | 0-1 | NAS-Port-Id | 0-1 | 0-1 | Termination-Action | 0-1 | 0-1 | ========== -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Fri Jun 7 17:51: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 RAA14180 for ; Fri, 7 Jun 2002 17:51:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8BB4F912DA; Fri, 7 Jun 2002 17:51:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52F98912DC; Fri, 7 Jun 2002 17:51:26 -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 72346912DA for ; Fri, 7 Jun 2002 17:51:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CF765DE0C; Fri, 7 Jun 2002 17:51:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 29C075DDA4 for ; Fri, 7 Jun 2002 17:51:20 -0400 (EDT) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 153D57C for ; Fri, 7 Jun 2002 17:51:28 -0400 (EDT) Message-ID: <3D012B25.ED7B8FF8@Interlinknetworks.com> Date: Fri, 07 Jun 2002 17:52:37 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: NASREQ Editor's Web Page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Announcing the NASREQ Editor's Web Page! http://ext.interlinknetworks.com/dspence/nasreq.html In order to give some visibility into the Diameter NASREQ editing process, I have created a NASREQ Editor's web page. On it you will find a link to the most recent NASREQ issues list showing the up-to-date status of all NASREQ issues. On it you will also find interim versions of the NASREQ draft that have not been submitted to the Internet Draft Repository. These interim versions aren't always pretty, but at least you can always take a peak at the very latest working copy. The goal for NASREQ is to resolve current open issues, strip out the EAP and key distribution sections, and release a new draft by the 54th IETF draft deadline of July 1. If all the editing can be done by then and if there are no unexpected delays in resolving issues or dealing with new issues, then NASREQ could be ready for another WG last call starting July 1. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Fri Jun 7 18:54: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 SAA15985 for ; Fri, 7 Jun 2002 18:54:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13A8791209; Fri, 7 Jun 2002 18:54:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF7CC912DC; Fri, 7 Jun 2002 18:54: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 94A0F91209 for ; Fri, 7 Jun 2002 18:54:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC35F5DDF5; Fri, 7 Jun 2002 18:54:12 -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 65B5C5DDA4 for ; Fri, 7 Jun 2002 18:54:12 -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 g57MsKi11265; Fri, 7 Jun 2002 17:54:20 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g57MsJb02123; Fri, 7 Jun 2002 17:54:19 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA29859; Fri, 7 Jun 2002 17:54:19 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA16379; Fri, 7 Jun 2002 17:54:17 -0500 (CDT) Message-ID: <3D0138B3.4654B4B6@ericsson.com> Date: Fri, 07 Jun 2002 15:50:27 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.com> <3CFE7134.DAD3DC77@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello David, I'm sorry that I haven't replied earlier. Before I start to comment on your proposal below. I think we really have to start by looking at how we define a stateless versus stateful Diameter agent in the Base protocol. Looking at section 2.8 Role of Diameter Agents, the following are stated : ".... The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, its Hop-by-Hop identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state. ... A stateful agent is one that maintains session state information; by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise, or by expiration. Each authorized session has an expiration, which is communicated by Diameter servers via the Session-Timeout AVP. ...." So, given the above, where it is clearly stated that a "stateless agent is one that only maintains transaction state", can we really claim that a AAAH can be stateless? If we both agree that the AAAH can not be stateless according to this protocol definition, then just have to remove the last sentence from the following paragraph on page 10 in MIP-10: " During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see Figure 2). If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR. " Regards, /Tony David Spence wrote: > Without attempting to go through all the scenarios or draft all the text > to be added to mobileip-10, here is my proposal for how to resolve issue > 336 (Clarify relationship between auth and accounting sessions) in a > good way. > > These are my goals: > > 1. Create a one-to-one correspondence between FA sessions and HA > sessions so that for each FA session there will be a single HA > session for the same MN that starts and ends at approximately the > same time as the FA session it corresponds to. > > 2. Diameter MobileIPv4 accounting sessions should exactly match the > authorization sessions and have the same Session-Id. > > 3. Accounting servers should be able to match the FA accounting > records to the HA accounting records for a given MN. > > 4. AAAH Diameter Servers need not be session stateful. The protocol > should work the same way whether Diameter Servers are session > stateful or not. > > 5. A domain should be able to have more than one Diameter Server > fulfilling the AAAH role. > > > The following are the general principles governing HA sessions. The > first two principles exist today. I am merely restating them to > emphasize that I am not changing them. > > 1. An HA session begins when a Diameter Server sends an HAR command > to an HA and receives an HAA command in response. > > 2. An HA session should normally end when an HA sends an STR command > to a Diameter Server and receives an STA command in response. > > Discussion: > > When an AAAH receives an STR command from an AAAF for an FA > session, it does not attempt to terminate the corresponding HA > session by sending an ASR command. The HA will find out via > the Mobile IP protocol that the session has ended and will send > and STR to the AAAH. It is important to maintain this > principle because the AAAH may not be aware of a pending > handoff. If the HA were to terminate a session before > commencing a new session for the pending handoff, the > multi-session would terminate and the handoff would then fail. > > 3. When an AAAH receives an AMR command that represents a new FA > session -- whether for a new multi-session or for a handoff within > an existing multi-session -- it generates an HAR command with a > new Session-Id. > > 4. When an HA receives an HAR command for a new session within a > multi-session, it generates an HAA in response and also generates > an ACR command with Accounting-Record-Type of START_RECORD. > > 5. When an HA terminates a session within a multi-session, it > generates an STR command and also generates an ACR command with > Accounting-Record-Type of STOP_RECORD. > > Principle number 3, above, cannot be implemented without a slight > protocol change. First of all, I don't know that there is any way that > a non-stateful AAAH can distinguish an AMR for a new session from a > reauth AMR for an existing session. Furthermore, for a reauth, the AAAH > must include the Session-Id in the HAR that identifies the > reauthenticated/reauthorized session. If the AAAH is stateless, it has > no way of knowing what Session-Id to use. Similarly if the AMR for the > reauth is sent to a different AAAH, the second AAAH will not know what > Session-Id to use in the HAR. In both of these cases, this problem is > currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER > PROTOCOL. In both of these cases, the AAAH generates a new value for > the Session-Id. The HA cannot rely on the Session-Id in a reauth HAR to > identify the session being reauthenticated/reauthorized. It must find > the session some other way. > > In order to fix the Diameter-MobileIPv4 protocol so that it works > correctly, I propose to define two new AVPs: > > FA-Session-Id > > This AVP is inserted in HAR commands by the AAAH to indicate the > Session-Id of the corresponding FA session. It is inserted in ACR > commands along with the MIP-Foreign-Agent-Host AVP by the HA to > identify the corresponding FA session to the accounting server. > > HA-Session-Id > > This AVP is inserted in AMA commands by the AAAH to indicate the > Session-Id of the corresponding HA session. It is inserted in > subsequent AMR commands for the same session by the FA. When > generating a HAR command, if the corresponding AMR command > contains an HA-Session-Id AVP, then the AAAH includes the value of > the HA-Session-Id AVP in the Session-Id AVP it inserts in the HAR. > Otherwise it generates a new value for the Session-Id it inserts > in the HAR. The FA also inserts the HA-Session-Id AVP in ACR > commands to identify the corresponding HA session to the > accounting server. > > This proposal requires no changes to the base protocol except to remove the > following stipulation that may have been added in an earlier attempt to > resolve issue 336: > > Accounting messages MAY use a different Session-Id from that sent in > authorization messages. Specific applications MAY require different > a Session-ID for accounting messages. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Sat Jun 8 12:22: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 MAA09051 for ; Sat, 8 Jun 2002 12:22:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2825912F0; Sat, 8 Jun 2002 12:22:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81E45912F1; Sat, 8 Jun 2002 12:22:46 -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 949FD912F0 for ; Sat, 8 Jun 2002 12:22:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D06D5DE4C; Sat, 8 Jun 2002 12:22:41 -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 9A14F5DE2F for ; Sat, 8 Jun 2002 12:22:36 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g58FXId20005 for ; Sat, 8 Jun 2002 08:33:18 -0700 Date: Sat, 8 Jun 2002 08:33:18 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG roadmap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The Diameter Base-10, MIP-10 and Transport-07 documents have completed AAA WG last call. The Base -11 document has incorporated last call comments and will appear on the IETF archive within a few days. No changes to the Transport-07 document resulted from WG last call. Last call comments and resolutions are available for inspection at: http://www.drizzle.com/~aboba/AAA/issues.html The current plan is to forward the Base-11 and Transport-07 documents to the IESG for IETF last call and consideration as IETF Proposed Standards within the next week. The MIP document is held up pending resolution of normative references to the CMS document. Luis Sanchez has agreed to do a review of this, in order to make a recommendation on how we should proceed. However, that review has not yet been completed. As requested by 3GPP2, David Spence and David Mitton are working on splitting off the EAP-related sections of the NASREQ document, in order to allow the non-EAP portion of NASREQ to be brought to AAA WG last call. As soon as the non-EAP portion of NASREQ hits the IETF archive (prior to the June 24 deadline), we will start AAA WG last call on that document. Given that the Base, MIP, Transport and non-EAP NASREQ documents will all be in various stages of AAA WG and IETF last call, there does not appear to be a need for the AAA WG to meet at IETF 54 in Yokahama. Instead, in the coming weeks we will focus on resolving the MIP/CMS issue, and incorporating changes arising from IESG and IETF last call comments on Base and Transport and AAA WG last call comments on non-EAP NASREQ. From owner-aaa-wg@merit.edu Sat Jun 8 16:14: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 QAA11224 for ; Sat, 8 Jun 2002 16:14:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECAEF91201; Sat, 8 Jun 2002 16:14:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67DE691230; Sat, 8 Jun 2002 16:14: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 371D591201 for ; Sat, 8 Jun 2002 16:14:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B51A05DE55; Sat, 8 Jun 2002 16:14:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9FC255DE19 for ; Sat, 8 Jun 2002 16:14:13 -0400 (EDT) Received: from Interlinknetworks.com (3com1a103.rc.net [152.160.53.103]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5E66E7B; Sat, 8 Jun 2002 16:14:18 -0400 (EDT) Message-ID: <3D0265DF.67CE7908@Interlinknetworks.com> Date: Sat, 08 Jun 2002 16:15:27 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.com> <3CFE7134.DAD3DC77@Interlinknetworks.com> <3D0138B3.4654B4B6@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, First of all, I am not sure that I do agree that an AAAH cannot be stateless. Our initial implementation of a Diameter server was stateless and at the time we thought that we could correctly implement the protocol. I am not aware of any reason other than this issue that would prevent an AAAH from being session stateless. If you know of any, I would very much appreciate it if you would let me know. But let's suppose that we did require an AAAH to be session stateful. In that case, would you also require that if a domain ran multiple AAAH's, then they would be required to implement a proprietary mechanism to share state with each other? If not, then you would have a problem if an original authorization were handled by AAAH1 and a subsequent reauth were handled by AAAH2. The problem would be that AAAH2 would not know what Session-Id to put in the HAR. So let's further suppose that if multiple AAAH's exist in a domain they MUST be able to access each other's session state database. In that case, I think that simply deleting the last sentence ("Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR") would technically suffice. I would probably want to strengthen the last phrase of the preceding sentence ("on behalf of a given mobile node's session"), however, to make it clear that "session" means session and not multi-session. That is, if an AAAH sends an HAR for a handoff of a mobile node's session (where the AMR that triggers it bears a different Session-Id from the AMR that produced the previous HAR), then the AAAH MUST generate a new Session-Id for the new HAR. Of course, a stateful AAAH would be able to do that. I think, however, that creating the two AVPs I defined below is all that is needed both to alleviate the AAAH from having to be stateful and to allow multiple AAAH's in a domain not to have to share state. Defining these two AVPs has the added benefit of helping an accounting server to match FA accounting records to HA accounting records for corresponding sessions. Dave Tony Johansson wrote: > > Hello David, > > I'm sorry that I haven't replied earlier. > > Before I start to comment on your proposal below. I think we really have to > start by looking at how we define a stateless versus stateful Diameter agent in > the Base protocol. > > Looking at section 2.8 Role of Diameter Agents, the following are stated : > > ".... > > The Diameter protocol requires that agents maintain transaction > state, which is used for failover purposes. Transaction state implies > that upon forwarding a request, its Hop-by-Hop identifier is saved; > the field is replaced with a locally unique identifier, which is > restored to its original value when the corresponding answer is > received. The request's state is released upon receipt of the answer. > A stateless agent is one that only maintains transaction state. > ... > > A stateful agent is one that maintains session state information; by > keeping track of all authorized active sessions. Each authorized > session is bound to a particular service, and its state is considered > active either until it is notified otherwise, or by expiration. Each > authorized session has an expiration, which is communicated by > Diameter servers via the Session-Timeout AVP. > ...." > > So, given the above, where it is clearly stated that a "stateless agent is one > that only maintains transaction state", can we really claim that a AAAH can be > stateless? If we both agree that the AAAH can not be stateless according to this > protocol definition, then just have to remove the last sentence from the > following paragraph on page 10 in MIP-10: > > " > During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see Figure 2). If the > AAAH is session-stateful, it MUST send the same session identifier > for all HARs initiated on behalf of a given mobile node's session. > Otherwise, if the AAAH is session-stateless, it will manufacture a > unique session-id for every HAR. " > > Regards, > > /Tony > > David Spence wrote: > > > Without attempting to go through all the scenarios or draft all the text > > to be added to mobileip-10, here is my proposal for how to resolve issue > > 336 (Clarify relationship between auth and accounting sessions) in a > > good way. > > > > These are my goals: > > > > 1. Create a one-to-one correspondence between FA sessions and HA > > sessions so that for each FA session there will be a single HA > > session for the same MN that starts and ends at approximately the > > same time as the FA session it corresponds to. > > > > 2. Diameter MobileIPv4 accounting sessions should exactly match the > > authorization sessions and have the same Session-Id. > > > > 3. Accounting servers should be able to match the FA accounting > > records to the HA accounting records for a given MN. > > > > 4. AAAH Diameter Servers need not be session stateful. The protocol > > should work the same way whether Diameter Servers are session > > stateful or not. > > > > 5. A domain should be able to have more than one Diameter Server > > fulfilling the AAAH role. > > > > > > The following are the general principles governing HA sessions. The > > first two principles exist today. I am merely restating them to > > emphasize that I am not changing them. > > > > 1. An HA session begins when a Diameter Server sends an HAR command > > to an HA and receives an HAA command in response. > > > > 2. An HA session should normally end when an HA sends an STR command > > to a Diameter Server and receives an STA command in response. > > > > Discussion: > > > > When an AAAH receives an STR command from an AAAF for an FA > > session, it does not attempt to terminate the corresponding HA > > session by sending an ASR command. The HA will find out via > > the Mobile IP protocol that the session has ended and will send > > and STR to the AAAH. It is important to maintain this > > principle because the AAAH may not be aware of a pending > > handoff. If the HA were to terminate a session before > > commencing a new session for the pending handoff, the > > multi-session would terminate and the handoff would then fail. > > > > 3. When an AAAH receives an AMR command that represents a new FA > > session -- whether for a new multi-session or for a handoff within > > an existing multi-session -- it generates an HAR command with a > > new Session-Id. > > > > 4. When an HA receives an HAR command for a new session within a > > multi-session, it generates an HAA in response and also generates > > an ACR command with Accounting-Record-Type of START_RECORD. > > > > 5. When an HA terminates a session within a multi-session, it > > generates an STR command and also generates an ACR command with > > Accounting-Record-Type of STOP_RECORD. > > > > Principle number 3, above, cannot be implemented without a slight > > protocol change. First of all, I don't know that there is any way that > > a non-stateful AAAH can distinguish an AMR for a new session from a > > reauth AMR for an existing session. Furthermore, for a reauth, the AAAH > > must include the Session-Id in the HAR that identifies the > > reauthenticated/reauthorized session. If the AAAH is stateless, it has > > no way of knowing what Session-Id to use. Similarly if the AMR for the > > reauth is sent to a different AAAH, the second AAAH will not know what > > Session-Id to use in the HAR. In both of these cases, this problem is > > currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER > > PROTOCOL. In both of these cases, the AAAH generates a new value for > > the Session-Id. The HA cannot rely on the Session-Id in a reauth HAR to > > identify the session being reauthenticated/reauthorized. It must find > > the session some other way. > > > > In order to fix the Diameter-MobileIPv4 protocol so that it works > > correctly, I propose to define two new AVPs: > > > > FA-Session-Id > > > > This AVP is inserted in HAR commands by the AAAH to indicate the > > Session-Id of the corresponding FA session. It is inserted in ACR > > commands along with the MIP-Foreign-Agent-Host AVP by the HA to > > identify the corresponding FA session to the accounting server. > > > > HA-Session-Id > > > > This AVP is inserted in AMA commands by the AAAH to indicate the > > Session-Id of the corresponding HA session. It is inserted in > > subsequent AMR commands for the same session by the FA. When > > generating a HAR command, if the corresponding AMR command > > contains an HA-Session-Id AVP, then the AAAH includes the value of > > the HA-Session-Id AVP in the Session-Id AVP it inserts in the HAR. > > Otherwise it generates a new value for the Session-Id it inserts > > in the HAR. The FA also inserts the HA-Session-Id AVP in ACR > > commands to identify the corresponding HA session to the > > accounting server. > > > > This proposal requires no changes to the base protocol except to remove the > > following stipulation that may have been added in an earlier attempt to > > resolve issue 336: > > > > Accounting messages MAY use a different Session-Id from that sent in > > authorization messages. Specific applications MAY require different > > a Session-ID for accounting messages. > > > > -- > > David Spence email: DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: +1 734 821 1203 > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > Ann Arbor, MI 48108 > > U.S.A. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Sat Jun 8 22:14: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 WAA15245 for ; Sat, 8 Jun 2002 22:14:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9E1491208; Sat, 8 Jun 2002 22:06:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93ECC9120C; Sat, 8 Jun 2002 22:06:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA35691208 for ; Sat, 8 Jun 2002 22:06:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 38FEE5DE2E; Sat, 8 Jun 2002 22:06: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 C589D5DD8D for ; Sat, 8 Jun 2002 22:06:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g591Gf619938; Sat, 8 Jun 2002 18:16:41 -0700 Date: Sat, 8 Jun 2002 18:16:40 -0700 (PDT) From: Bernard Aboba To: iesg@ietf.org Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG has completed WG last call on the Diameter Base-10 and Transport-07 documents. As a result of WG last call comments, no changes were made to the Transport document, and 20 changes were made to the Diameter Base document, with 5 comments rejected. Based on this, the AAA WG recommends that the IESG initiate IETF last call on the following documents, followed by consideration as IETF Proposed Standards: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-11.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-07.txt Comments received during this and previous AAA WG last calls (and their resolution) are available for inspection at: http://www.drizzle.com/~aboba/AAA/issues.html This includes issues previously raised by the IESG, including Issues #268, 269 and 342. From owner-aaa-wg@merit.edu Sun Jun 9 00:32:48 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 AAA16839 for ; Sun, 9 Jun 2002 00:32:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49AA59121B; Sun, 9 Jun 2002 00:32:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B8F391225; Sun, 9 Jun 2002 00:32: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 906009121B for ; Sun, 9 Jun 2002 00:32:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D8E35DE35; Sun, 9 Jun 2002 00:32:40 -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 F11135DDA7 for ; Sun, 9 Jun 2002 00:32:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GuNj-0001H0-00; Sat, 08 Jun 2002 21:32:47 -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]: Request for IETF last call on Diameter-11 and Transport-07 drafts References: Message-Id: Date: Sat, 08 Jun 2002 21:32:47 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The AAA WG has completed WG last call on the Diameter Base-10 and > Transport-07 documents. As a result of WG last call comments, no > changes were made to the Transport document, and 20 changes were > made to the Diameter Base document, with 5 comments rejected. as ad, i will not be passing this to the iesg for review. there is one comment that has not been addressed by -11, vendor-specific commands. as i have repeatedly said, if i was to pass this to the iesg, it is a sure show-stopper. rather than saying it all over again, can folk please review the mailing list archive on this. essentially, the iesg has a hot- button about mandatory vendor commands. randy From owner-aaa-wg@merit.edu Sun Jun 9 16:10: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 QAA06979 for ; Sun, 9 Jun 2002 16:10:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9974E9120A; Sun, 9 Jun 2002 16:11:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B5AA91226; Sun, 9 Jun 2002 16:11:06 -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 3BA6B9120A for ; Sun, 9 Jun 2002 16:11:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94C885DDE2; Sun, 9 Jun 2002 16:11:00 -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 3DCFD5DDDF for ; Sun, 9 Jun 2002 16:11:00 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g59KB8l06440; Sun, 9 Jun 2002 15:11:08 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g59KB7Q17238; Sun, 9 Jun 2002 15:11:08 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA06363; Sun, 9 Jun 2002 15:11:07 -0500 (CDT) Received: from ericsson.com (letmein2-026.exu.ericsson.se [138.85.130.26]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA09233; Sun, 9 Jun 2002 15:11:05 -0500 (CDT) Message-ID: <3D03B571.30768671@ericsson.com> Date: Sun, 09 Jun 2002 13:07:13 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.com> <3CFE7134.DAD3DC77@Interlinknetworks.com> <3D0138B3.4654B4B6@ericsson.com> <3D0265DF.67CE7908@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, all, David Spence wrote: > Tony, > > First of all, I am not sure that I do agree that an AAAH cannot be > stateless. Our initial implementation of a Diameter server was stateless > and at the time we thought that we could correctly implement the protocol. > I am not aware of any reason other than this issue that would prevent an > AAAH from being session stateless. If you know of any, I would very much > appreciate it if you would let me know. Being session stateless according to the Base protocol is that you only maintains transaction state. However, a MIP AAAH server do have to handle the authentication, authorization, etc of the user, and furthermore must expect to get STRs or send ABRs for an expired session-id that an active user may have, so strictly form a protocol prospective, can you really say that the MIP AAAH server can be a stateless Diameter agent? Furthermore, based on all the previous session stateless AAAH discussions, implementing the MIP application with a *session stateless* AAAH wouldn't you still store the FA session id and the HA session id in the AAAH (or in away that the AAAH easily can retrieve them (e.g. through a back ended database)) in order to deal with STRs from the HA, synchronizing the session id for accounting purposes, not having to send new session ids in every subsequent HAR, etc etc? > > > But let's suppose that we did require an AAAH to be session stateful. In > that case, would you also require that if a domain ran multiple AAAH's, then > they would be required to implement a proprietary mechanism to share state > with each other? No, that's why we have agree to add support for the AAA NAI for Mobile IPv4 Extension (http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-02.txt) and added text through out the MIP application for the support of multiple AAAH's. Please see further info from previous mail threads on issue 299 and 301, and presentation made at IETF53. > If not, then you would have a problem if an original > authorization were handled by AAAH1 and a subsequent reauth were handled by > AAAH2. The problem would be that AAAH2 would not know what Session-Id to > put in the HAR. See above. > > > So let's further suppose that if multiple AAAH's exist in a domain they MUST > be able to access each other's session state database. In that case, I > think that simply deleting the last sentence ("Otherwise, if the AAAH is > session-stateless, it will manufacture a unique session-id for every HAR") > would technically suffice. I would probably want to strengthen the last > phrase of the preceding sentence ("on behalf of a given mobile node's > session"), however, to make it clear that "session" means session and not > multi-session. That is, if an AAAH sends an HAR for a handoff of a mobile > node's session (where the AMR that triggers it bears a different Session-Id > from the AMR that produced the previous HAR), then the AAAH MUST generate a > new Session-Id for the new HAR. Why should you change the session-id between the AAAH and HA just because you changed from one FA to another FA? IMHO, I would only change the session-id to HA only if you have move to another AAAH. Then it is very clear to the HA why the session-id is changed.. > Of course, a stateful AAAH would be able to > do that. > > I think, however, that creating the two AVPs I defined below is all that is > needed both to alleviate the AAAH from having to be stateful and to allow > multiple AAAH's in a domain not to have to share state. Defining these two > AVPs has the added benefit of helping an accounting server to match FA > accounting records to HA accounting records for corresponding sessions. I have no problems of added these new AVPs to the protocol. However, I really want us once and for all first get consensus on what a session stateless AAAH really means and based on that decide if the two new AVPs are needed. Does it make sense?! Best Regards, /Tony > > > Dave > > Tony Johansson wrote: > > > > Hello David, > > > > I'm sorry that I haven't replied earlier. > > > > Before I start to comment on your proposal below. I think we really have to > > start by looking at how we define a stateless versus stateful Diameter agent in > > the Base protocol. > > > > Looking at section 2.8 Role of Diameter Agents, the following are stated : > > > > ".... > > > > The Diameter protocol requires that agents maintain transaction > > state, which is used for failover purposes. Transaction state implies > > that upon forwarding a request, its Hop-by-Hop identifier is saved; > > the field is replaced with a locally unique identifier, which is > > restored to its original value when the corresponding answer is > > received. The request's state is released upon receipt of the answer. > > A stateless agent is one that only maintains transaction state. > > ... > > > > A stateful agent is one that maintains session state information; by > > keeping track of all authorized active sessions. Each authorized > > session is bound to a particular service, and its state is considered > > active either until it is notified otherwise, or by expiration. Each > > authorized session has an expiration, which is communicated by > > Diameter servers via the Session-Timeout AVP. > > ...." > > > > So, given the above, where it is clearly stated that a "stateless agent is one > > that only maintains transaction state", can we really claim that a AAAH can be > > stateless? If we both agree that the AAAH can not be stateless according to this > > protocol definition, then just have to remove the last sentence from the > > following paragraph on page 10 in MIP-10: > > > > " > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see Figure 2). If the > > AAAH is session-stateful, it MUST send the same session identifier > > for all HARs initiated on behalf of a given mobile node's session. > > Otherwise, if the AAAH is session-stateless, it will manufacture a > > unique session-id for every HAR. " > > > > Regards, > > > > /Tony > > > > David Spence wrote: > > > > > Without attempting to go through all the scenarios or draft all the text > > > to be added to mobileip-10, here is my proposal for how to resolve issue > > > 336 (Clarify relationship between auth and accounting sessions) in a > > > good way. > > > > > > These are my goals: > > > > > > 1. Create a one-to-one correspondence between FA sessions and HA > > > sessions so that for each FA session there will be a single HA > > > session for the same MN that starts and ends at approximately the > > > same time as the FA session it corresponds to. > > > > > > 2. Diameter MobileIPv4 accounting sessions should exactly match the > > > authorization sessions and have the same Session-Id. > > > > > > 3. Accounting servers should be able to match the FA accounting > > > records to the HA accounting records for a given MN. > > > > > > 4. AAAH Diameter Servers need not be session stateful. The protocol > > > should work the same way whether Diameter Servers are session > > > stateful or not. > > > > > > 5. A domain should be able to have more than one Diameter Server > > > fulfilling the AAAH role. > > > > > > > > > The following are the general principles governing HA sessions. The > > > first two principles exist today. I am merely restating them to > > > emphasize that I am not changing them. > > > > > > 1. An HA session begins when a Diameter Server sends an HAR command > > > to an HA and receives an HAA command in response. > > > > > > 2. An HA session should normally end when an HA sends an STR command > > > to a Diameter Server and receives an STA command in response. > > > > > > Discussion: > > > > > > When an AAAH receives an STR command from an AAAF for an FA > > > session, it does not attempt to terminate the corresponding HA > > > session by sending an ASR command. The HA will find out via > > > the Mobile IP protocol that the session has ended and will send > > > and STR to the AAAH. It is important to maintain this > > > principle because the AAAH may not be aware of a pending > > > handoff. If the HA were to terminate a session before > > > commencing a new session for the pending handoff, the > > > multi-session would terminate and the handoff would then fail. > > > > > > 3. When an AAAH receives an AMR command that represents a new FA > > > session -- whether for a new multi-session or for a handoff within > > > an existing multi-session -- it generates an HAR command with a > > > new Session-Id. > > > > > > 4. When an HA receives an HAR command for a new session within a > > > multi-session, it generates an HAA in response and also generates > > > an ACR command with Accounting-Record-Type of START_RECORD. > > > > > > 5. When an HA terminates a session within a multi-session, it > > > generates an STR command and also generates an ACR command with > > > Accounting-Record-Type of STOP_RECORD. > > > > > > Principle number 3, above, cannot be implemented without a slight > > > protocol change. First of all, I don't know that there is any way that > > > a non-stateful AAAH can distinguish an AMR for a new session from a > > > reauth AMR for an existing session. Furthermore, for a reauth, the AAAH > > > must include the Session-Id in the HAR that identifies the > > > reauthenticated/reauthorized session. If the AAAH is stateless, it has > > > no way of knowing what Session-Id to use. Similarly if the AMR for the > > > reauth is sent to a different AAAH, the second AAAH will not know what > > > Session-Id to use in the HAR. In both of these cases, this problem is > > > currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER > > > PROTOCOL. In both of these cases, the AAAH generates a new value for > > > the Session-Id. The HA cannot rely on the Session-Id in a reauth HAR to > > > identify the session being reauthenticated/reauthorized. It must find > > > the session some other way. > > > > > > In order to fix the Diameter-MobileIPv4 protocol so that it works > > > correctly, I propose to define two new AVPs: > > > > > > FA-Session-Id > > > > > > This AVP is inserted in HAR commands by the AAAH to indicate the > > > Session-Id of the corresponding FA session. It is inserted in ACR > > > commands along with the MIP-Foreign-Agent-Host AVP by the HA to > > > identify the corresponding FA session to the accounting server. > > > > > > HA-Session-Id > > > > > > This AVP is inserted in AMA commands by the AAAH to indicate the > > > Session-Id of the corresponding HA session. It is inserted in > > > subsequent AMR commands for the same session by the FA. When > > > generating a HAR command, if the corresponding AMR command > > > contains an HA-Session-Id AVP, then the AAAH includes the value of > > > the HA-Session-Id AVP in the Session-Id AVP it inserts in the HAR. > > > Otherwise it generates a new value for the Session-Id it inserts > > > in the HAR. The FA also inserts the HA-Session-Id AVP in ACR > > > commands to identify the corresponding HA session to the > > > accounting server. > > > > > > This proposal requires no changes to the base protocol except to remove the > > > following stipulation that may have been added in an earlier attempt to > > > resolve issue 336: > > > > > > Accounting messages MAY use a different Session-Id from that sent in > > > authorization messages. Specific applications MAY require different > > > a Session-ID for accounting messages. > > > > > > -- > > > David Spence email: DSpence@Interlinknetworks.com > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > Ann Arbor, MI 48108 > > > U.S.A. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Mon Jun 10 03:49:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24838 for ; Mon, 10 Jun 2002 03:49:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E8F691238; Mon, 10 Jun 2002 03:49:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 144689123A; Mon, 10 Jun 2002 03:49: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 DBBC791238 for ; Mon, 10 Jun 2002 03:49:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABD845DE7B; Mon, 10 Jun 2002 03:49:44 -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 BCE735DDF9 for ; Mon, 10 Jun 2002 03:49:43 -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 g5A7oiUg014445; Mon, 10 Jun 2002 09:50:44 +0200 From: "Fredrik Johansson" To: "David Spence" , "Tony Johansson" Cc: , , Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Date: Mon, 10 Jun 2002 09:50:19 +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.4133.2400 Importance: Normal In-Reply-To: <3D0265DF.67CE7908@Interlinknetworks.com> X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Please see comments below /Fredrik > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > David Spence > Sent: den 8 juni 2002 22:15 > To: Tony Johansson > Cc: john.loughney@nokia.com; johanj@ipunplugged.com; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and > accounting sessions > > > Tony, > > First of all, I am not sure that I do agree that an AAAH cannot be > stateless. Our initial implementation of a Diameter server was stateless > and at the time we thought that we could correctly implement the > protocol. > I am not aware of any reason other than this issue that would prevent an > AAAH from being session stateless. If you know of any, I would very much > appreciate it if you would let me know. > > But let's suppose that we did require an AAAH to be session stateful. In > that case, would you also require that if a domain ran multiple > AAAH's, then > they would be required to implement a proprietary mechanism to share state > with each other? If not, then you would have a problem if an original > authorization were handled by AAAH1 and a subsequent reauth were > handled by > AAAH2. The problem would be that AAAH2 would not know what Session-Id to > put in the HAR. That's why the HA must handle the case where it receives different session id's for the same session. The HA must recognize that it's the same session (using MN Address, HA address and NAI), it must then return the multi-session id to the new AAAH in order to maintain the original multisession. > > So let's further suppose that if multiple AAAH's exist in a > domain they MUST > be able to access each other's session state database. In that case, I > think that simply deleting the last sentence ("Otherwise, if the AAAH is > session-stateless, it will manufacture a unique session-id for every HAR") > would technically suffice. I would probably want to strengthen the last > phrase of the preceding sentence ("on behalf of a given mobile node's > session"), however, to make it clear that "session" means session and not > multi-session. That is, if an AAAH sends an HAR for a handoff of a mobile > node's session (where the AMR that triggers it bears a different > Session-Id > from the AMR that produced the previous HAR), then the AAAH MUST > generate a > new Session-Id for the new HAR. Of course, a stateful AAAH would > be able to > do that. > > I think, however, that creating the two AVPs I defined below is > all that is > needed both to alleviate the AAAH from having to be stateful and to allow > multiple AAAH's in a domain not to have to share state. Defining > these two > AVPs has the added benefit of helping an accounting server to match FA > accounting records to HA accounting records for corresponding sessions. > > Dave > > Tony Johansson wrote: > > > > Hello David, > > > > I'm sorry that I haven't replied earlier. > > > > Before I start to comment on your proposal below. I think we > really have to > > start by looking at how we define a stateless versus stateful > Diameter agent in > > the Base protocol. > > > > Looking at section 2.8 Role of Diameter Agents, the following > are stated : > > > > ".... > > > > The Diameter protocol requires that agents maintain transaction > > state, which is used for failover purposes. Transaction state implies > > that upon forwarding a request, its Hop-by-Hop identifier is saved; > > the field is replaced with a locally unique identifier, which is > > restored to its original value when the corresponding answer is > > received. The request's state is released upon receipt of the answer. > > A stateless agent is one that only maintains transaction state. > > ... > > > > A stateful agent is one that maintains session state information; by > > keeping track of all authorized active sessions. Each authorized > > session is bound to a particular service, and its state is considered > > active either until it is notified otherwise, or by expiration. Each > > authorized session has an expiration, which is communicated by > > Diameter servers via the Session-Timeout AVP. > > ...." > > > > So, given the above, where it is clearly stated that a > "stateless agent is one > > that only maintains transaction state", can we really claim > that a AAAH can be > > stateless? If we both agree that the AAAH can not be stateless > according to this > > protocol definition, then just have to remove the last sentence from the > > following paragraph on page 10 in MIP-10: > > > > " > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see Figure 2). If the > > AAAH is session-stateful, it MUST send the same session identifier > > for all HARs initiated on behalf of a given mobile node's session. > > Otherwise, if the AAAH is session-stateless, it will manufacture a > > unique session-id for every HAR. " > > > > Regards, > > > > /Tony > > > > David Spence wrote: > > > > > Without attempting to go through all the scenarios or draft > all the text > > > to be added to mobileip-10, here is my proposal for how to > resolve issue > > > 336 (Clarify relationship between auth and accounting sessions) in a > > > good way. > > > > > > These are my goals: > > > > > > 1. Create a one-to-one correspondence between FA sessions and HA > > > sessions so that for each FA session there will be a single HA > > > session for the same MN that starts and ends at > approximately the > > > same time as the FA session it corresponds to. > > > > > > 2. Diameter MobileIPv4 accounting sessions should exactly match the > > > authorization sessions and have the same Session-Id. > > > > > > 3. Accounting servers should be able to match the FA accounting > > > records to the HA accounting records for a given MN. > > > > > > 4. AAAH Diameter Servers need not be session stateful. > The protocol > > > should work the same way whether Diameter Servers are session > > > stateful or not. > > > > > > 5. A domain should be able to have more than one Diameter Server > > > fulfilling the AAAH role. > > > > > > > > > The following are the general principles governing HA sessions. The > > > first two principles exist today. I am merely restating them to > > > emphasize that I am not changing them. > > > > > > 1. An HA session begins when a Diameter Server sends an HAR command > > > to an HA and receives an HAA command in response. > > > > > > 2. An HA session should normally end when an HA sends an > STR command > > > to a Diameter Server and receives an STA command in response. > > > > > > Discussion: > > > > > > When an AAAH receives an STR command from an AAAF for an FA > > > session, it does not attempt to terminate the > corresponding HA > > > session by sending an ASR command. The HA will find out via > > > the Mobile IP protocol that the session has ended > and will send > > > and STR to the AAAH. It is important to maintain this > > > principle because the AAAH may not be aware of a pending > > > handoff. If the HA were to terminate a session before > > > commencing a new session for the pending handoff, the > > > multi-session would terminate and the handoff would > then fail. > > > > > > 3. When an AAAH receives an AMR command that represents a new FA > > > session -- whether for a new multi-session or for a > handoff within > > > an existing multi-session -- it generates an HAR command with a > > > new Session-Id. > > > > > > 4. When an HA receives an HAR command for a new session within a > > > multi-session, it generates an HAA in response and also > generates > > > an ACR command with Accounting-Record-Type of START_RECORD. > > > > > > 5. When an HA terminates a session within a multi-session, it > > > generates an STR command and also generates an ACR command with > > > Accounting-Record-Type of STOP_RECORD. > > > > > > Principle number 3, above, cannot be implemented without a slight > > > protocol change. First of all, I don't know that there is > any way that > > > a non-stateful AAAH can distinguish an AMR for a new session from a > > > reauth AMR for an existing session. Furthermore, for a > reauth, the AAAH > > > must include the Session-Id in the HAR that identifies the > > > reauthenticated/reauthorized session. If the AAAH is > stateless, it has > > > no way of knowing what Session-Id to use. Similarly if the > AMR for the > > > reauth is sent to a different AAAH, the second AAAH will not know what > > > Session-Id to use in the HAR. In both of these cases, this problem is > > > currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER > > > PROTOCOL. In both of these cases, the AAAH generates a new value for > > > the Session-Id. The HA cannot rely on the Session-Id in a > reauth HAR to > > > identify the session being reauthenticated/reauthorized. It must find > > > the session some other way. > > > > > > In order to fix the Diameter-MobileIPv4 protocol so that it works > > > correctly, I propose to define two new AVPs: > > > > > > FA-Session-Id > > > > > > This AVP is inserted in HAR commands by the AAAH to indicate the > > > Session-Id of the corresponding FA session. It is > inserted in ACR > > > commands along with the MIP-Foreign-Agent-Host AVP by the HA to > > > identify the corresponding FA session to the accounting server. > > > > > > HA-Session-Id > > > > > > This AVP is inserted in AMA commands by the AAAH to indicate the > > > Session-Id of the corresponding HA session. It is inserted in > > > subsequent AMR commands for the same session by the FA. When > > > generating a HAR command, if the corresponding AMR command > > > contains an HA-Session-Id AVP, then the AAAH includes > the value of > > > the HA-Session-Id AVP in the Session-Id AVP it inserts > in the HAR. > > > Otherwise it generates a new value for the Session-Id it inserts > > > in the HAR. The FA also inserts the HA-Session-Id AVP in ACR > > > commands to identify the corresponding HA session to the > > > accounting server. > > > > > > This proposal requires no changes to the base protocol except > to remove the > > > following stipulation that may have been added in an earlier > attempt to > > > resolve issue 336: > > > > > > Accounting messages MAY use a different Session-Id from > that sent in > > > authorization messages. Specific applications MAY require > different > > > a Session-ID for accounting messages. > > > > > > -- > > > David Spence email: > DSpence@Interlinknetworks.com > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > Ann Arbor, MI 48108 > > > U.S.A. > > -- > David Spence email: > DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Mon Jun 10 09:19:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02806 for ; Mon, 10 Jun 2002 09:19:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0100C91252; Mon, 10 Jun 2002 09:19:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9207991254; Mon, 10 Jun 2002 09:19: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 F406D91252 for ; Mon, 10 Jun 2002 09:18:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D82615DDA7; Mon, 10 Jun 2002 09:18:52 -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 385935DDB0 for ; Mon, 10 Jun 2002 09:18:52 -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 g5ADHgF00491 for ; Mon, 10 Jun 2002 16:17:43 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Jun 2002 16:18:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 16:18:59 +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]: Issue: Removal of vendor-specific Diameter command-codes Date: Mon, 10 Jun 2002 16:18:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E48@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07drafts Thread-Index: AcIP1VLqxyXY+1/1RiGBJWRPIatbzwAqgprw X-Priority: 1 Importance: high From: To: , Cc: X-OriginalArrivalTime: 10 Jun 2002 13:18:59.0311 (UTC) FILETIME=[618AD7F0:01C21081] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA02806 Hi all, If I have understood Randy Bush correctly, the IESG strongly objects to the inclusion of support for vendor-specific command-codes in the Diameter Base Protocol. The modifications needed to remove these are as follows: 1) removal of Vendor-ID from the Diameter Header. 2) removal vendor-specific command-codes from 5.3.6 3) vendor-specific Diameter command-codes from 6.11 4) Discussion of vendor-specific Diameter command-codes in section 11.2.1 Below is the current text from Diameter 11 that discusses vendor-specific command-codes. Again, the proposal is that all mention of vendor-specific command-codes would be removed. Please comment on the list. thanks, John ============ 3 Diameter Header [text clipped] Vendor-ID 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" [ASSIGNNO] 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 vendor's vendor-specific command, nor with future IETF applications. All vendor-specific Diameter commands require Informational RFCs documenting the command unless for Private Use as described in Section 11.1.1. -> (11.1.1 needs to be changed to 11.2.1) ===== 5.3.6 Supported-Vendor-Id AVP The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value assigned to a vendor other than the device vendor. This is used in the CER and CEA messages in order to inform the peer that the sender supports a subset of the vendor-specific commands and/or AVPs defined by the vendor identified in this AVP. ===== 6.11 Vendor-Specific-Application-Id AVP The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present. This AVP MUST also be present in all vendor-specific commands defined in the vendor-specific application. This AVP SHOULD be placed as close to the Diameter header as possible. AVP Format ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } ===== 11.2.1 Command Codes The Command Code namespace is used to identify Diameter commands. The values 0-255 are reserved for RADIUS backward compatibility, and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. The remaining values are available via Standards Action [IANA]. Vendor-Specific Command Codes, where the Vendor-Id field in the Diameter header is set to a non-zero value, are for Private Use. From owner-aaa-wg@merit.edu Mon Jun 10 09:22:19 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 JAA02858 for ; Mon, 10 Jun 2002 09:22:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F92C91237; Mon, 10 Jun 2002 09:22:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D37D491243; Mon, 10 Jun 2002 09:22:12 -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 AAEC991237 for ; Mon, 10 Jun 2002 09:22:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 955995DDAA; Mon, 10 Jun 2002 09:22:07 -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 BC9A55DDA7 for ; Mon, 10 Jun 2002 09:22:06 -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 g5ADNsa04660 for ; Mon, 10 Jun 2002 16:23:55 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Jun 2002 16:22:14 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 16:22: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-8859-1" Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts Date: Mon, 10 Jun 2002 16:22:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653BD@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts Thread-Index: AcIPbsO/ntLguCPuQqaKsMKdHeuBsABEushQ X-Priority: 1 Importance: high From: To: , Cc: X-OriginalArrivalTime: 10 Jun 2002 13:22:13.0867 (UTC) FILETIME=[D581BBB0:01C21081] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA02858 Hi all, > as ad, i will not be passing this to the iesg for review. there > is one comment that has not been addressed by -11, vendor-specific > commands. as i have repeatedly said, if i was to pass this to the > iesg, it is a sure show-stopper. > > rather than saying it all over again, can folk please review the > mailing list archive on this. essentially, the iesg has a hot- > button about mandatory vendor commands. As a service to the mailing list, I think Randy document his concern about Diameter extensibility here. I hope he will let me know if this is still an accurate representation of the issue. Thanks, John [AAA-WG]: Re: Diameter extensibility From: Randy Bush Date: Sat Dec 29 13:58:14 2001 -------------------------------------------------------------------------------- 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. randy From owner-aaa-wg@merit.edu Mon Jun 10 10:34: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 KAA05953 for ; Mon, 10 Jun 2002 10:34:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86E889124C; Mon, 10 Jun 2002 10:34:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 527909124E; Mon, 10 Jun 2002 10:34: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 690499124C for ; Mon, 10 Jun 2002 10:34:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 52B095DDFC; Mon, 10 Jun 2002 10:34:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 3C3DB5DD97 for ; Mon, 10 Jun 2002 10:34:54 -0400 (EDT) Received: from Interlinknetworks.com (3com1a71.rc.net [152.160.53.71]) by aaa.interlinknetworks.com (Postfix) with ESMTP id A01857B; Mon, 10 Jun 2002 10:34:58 -0400 (EDT) Message-ID: <3D04B959.8DE94178@Interlinknetworks.com> Date: Mon, 10 Jun 2002 10:36:09 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Johansson Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.com> <3CFE7134.DAD3DC77@Interlinknetworks.com> <3D0138B3.4654B4B6@ericsson.com> <3D0265DF.67CE7908@Interlinknetworks.com> <3D03B571.30768671@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, See comments inline. Tony Johansson wrote: > > Hi David, all, > > David Spence wrote: > > > Tony, > > > > First of all, I am not sure that I do agree that an AAAH cannot be > > stateless. Our initial implementation of a Diameter server was stateless > > and at the time we thought that we could correctly implement the protocol. > > I am not aware of any reason other than this issue that would prevent an > > AAAH from being session stateless. If you know of any, I would very much > > appreciate it if you would let me know. > > Being session stateless according to the Base protocol is that you only maintains > transaction state. However, a MIP AAAH server do have to handle the authentication, > authorization, etc of the user, I don't think auth/auth mandates being session stateful. > and furthermore must expect to get STRs A session-stateless AAAH doesn't really have to do anything with an FA-generated STR except perhaps to write it to a log file. Is the same not true of an HA-generated STR? If an AAAH receives an STR from an HA, it is not required to send an ABR to the FA is it? The FA will see the tunnel go down and generate an STR. > or send ABRs for an expired session-id that an active user may have, ABRs and session timeouts are defined in the base protocol. My understanding is that the home Diameter server is not required to send an ABR to enforce a timeout. That is the responsibility of the Diameter client. > so strictly form a protocol > prospective, can you really say that the MIP AAAH server can be a stateless Diameter > agent? Yes, the AAAH can be a stateless Diameter node! (It is not a Diameter agent, strictly speaking.) > > Furthermore, based on all the previous session stateless AAAH discussions, > implementing the MIP application with a *session stateless* AAAH wouldn't you still > store the FA session id and the HA session id in the AAAH (or in away that the AAAH > easily can retrieve them (e.g. through a back ended database)) in order to deal with > STRs from the HA, Once again, I didn't think it was necessary to match Session-Ids in order to handle HA STRs. Am I mistaken about this? > synchronizing the session id for accounting purposes, That is a problem for the accounting server and is ordinarily done in the post processing. Of course, either an accounting server or an AAAH MAY be session-stateful if it wishes to keep track of such things in real time instead of in the post-processing. > not having to send new session ids in every subsequent HAR, etc etc? Well, now you're begging the question. This is the problem I was trying to solve by defining the HA-Session-Id AVP. Certainly a session-stateful AAAH could match FA Session-Ids to HA-Session-Ids without the new AVP. However, I still believe that this is the only problem that cannot be solved by a session-stateless AAAH. > > > > > > > But let's suppose that we did require an AAAH to be session stateful. In > > that case, would you also require that if a domain ran multiple AAAH's, then > > they would be required to implement a proprietary mechanism to share state > > with each other? > > No, that's why we have agree to add support for the AAA NAI for Mobile IPv4 Extension > (http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-02.txt) and added > text through out the MIP application for the support of multiple AAAH's. But the AAA NAI does not carry the HA-Session-Id AVP. So if AAAH's are session-stateful, but the AAAH's in a domain cannot share session state, then if a reauth AMR arrives at a different AAAH than the one that processed the original AMR, the AAAH processing the reauth AMR has no way to know the value of the Session-Id AVP it needs to insert in the HAR it sends to the HA. So your proposed requirement that AAAH's be session stateful fails unless you also also require that multiple AAAH's in a domain have a mechanism to share session state with each other. My proposal, however, correctly supports multiple AAAH's as well as stateless AAAH's. > Please see further info from previous mail threads on issue 299 and 301, > and presentation made at IETF53. I am well aware of the discussion on issues 299 and 301. My colleague Bob Kopacz submitted those issues, and I followed them closely. They do not apply to this case, however. > > > If not, then you would have a problem if an original > > authorization were handled by AAAH1 and a subsequent reauth were handled by > > AAAH2. The problem would be that AAAH2 would not know what Session-Id to > > put in the HAR. > > See above. See what, above? You have not explained how AAAH2 could possibly know what Session-Id to put in the HAR -- unless you added the HA Session-Id to the NAI extension when I wasn't looking. > > > > > > > So let's further suppose that if multiple AAAH's exist in a domain they MUST > > be able to access each other's session state database. In that case, I > > think that simply deleting the last sentence ("Otherwise, if the AAAH is > > session-stateless, it will manufacture a unique session-id for every HAR") > > would technically suffice. I would probably want to strengthen the last > > phrase of the preceding sentence ("on behalf of a given mobile node's > > session"), however, to make it clear that "session" means session and not > > multi-session. That is, if an AAAH sends an HAR for a handoff of a mobile > > node's session (where the AMR that triggers it bears a different Session-Id > > from the AMR that produced the previous HAR), then the AAAH MUST generate a > > new Session-Id for the new HAR. > > Why should you change the session-id between the AAAH and HA just because you changed > from one FA to another FA? IMHO, I would only change the session-id to HA only if you > have move to another AAAH. Then it is very clear to the HA why the session-id is > changed.. The reason I would change the Session-Id between the AAAH and HA is so that the HA accounting records will have the same scope as the FA accounting records. I believe that many home service providers will consider this ESSENTIAL! Furthermore, you MUST NOT change the Session-Id simply because a second AAAH got involved. This is the reauth case discussed above. Not maintaining Session-Id in a reauth is a breach of the Diameter base protocol!!! > > > Of course, a stateful AAAH would be able to > > do that. > > > > I think, however, that creating the two AVPs I defined below is all that is > > needed both to alleviate the AAAH from having to be stateful and to allow > > multiple AAAH's in a domain not to have to share state. Defining these two > > AVPs has the added benefit of helping an accounting server to match FA > > accounting records to HA accounting records for corresponding sessions. > > I have no problems of added these new AVPs to the protocol. However, I really want us > once and for all first get consensus on what a session stateless AAAH really means and > based on that decide if the two new AVPs are needed. I don't think there has ever been a question about what a session-stateless AAAH really means. > > Does it make sense?! > > Best Regards, > > /Tony > > > > > > > Dave > > > > Tony Johansson wrote: > > > > > > Hello David, > > > > > > I'm sorry that I haven't replied earlier. > > > > > > Before I start to comment on your proposal below. I think we really have to > > > start by looking at how we define a stateless versus stateful Diameter agent in > > > the Base protocol. > > > > > > Looking at section 2.8 Role of Diameter Agents, the following are stated : > > > > > > ".... > > > > > > The Diameter protocol requires that agents maintain transaction > > > state, which is used for failover purposes. Transaction state implies > > > that upon forwarding a request, its Hop-by-Hop identifier is saved; > > > the field is replaced with a locally unique identifier, which is > > > restored to its original value when the corresponding answer is > > > received. The request's state is released upon receipt of the answer. > > > A stateless agent is one that only maintains transaction state. > > > ... > > > > > > A stateful agent is one that maintains session state information; by > > > keeping track of all authorized active sessions. Each authorized > > > session is bound to a particular service, and its state is considered > > > active either until it is notified otherwise, or by expiration. Each > > > authorized session has an expiration, which is communicated by > > > Diameter servers via the Session-Timeout AVP. > > > ...." > > > > > > So, given the above, where it is clearly stated that a "stateless agent is one > > > that only maintains transaction state", can we really claim that a AAAH can be > > > stateless? If we both agree that the AAAH can not be stateless according to this > > > protocol definition, then just have to remove the last sentence from the > > > following paragraph on page 10 in MIP-10: > > > > > > " > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see Figure 2). If the > > > AAAH is session-stateful, it MUST send the same session identifier > > > for all HARs initiated on behalf of a given mobile node's session. > > > Otherwise, if the AAAH is session-stateless, it will manufacture a > > > unique session-id for every HAR. " > > > > > > Regards, > > > > > > /Tony > > > > > > David Spence wrote: > > > > > > > Without attempting to go through all the scenarios or draft all the text > > > > to be added to mobileip-10, here is my proposal for how to resolve issue > > > > 336 (Clarify relationship between auth and accounting sessions) in a > > > > good way. > > > > > > > > These are my goals: > > > > > > > > 1. Create a one-to-one correspondence between FA sessions and HA > > > > sessions so that for each FA session there will be a single HA > > > > session for the same MN that starts and ends at approximately the > > > > same time as the FA session it corresponds to. > > > > > > > > 2. Diameter MobileIPv4 accounting sessions should exactly match the > > > > authorization sessions and have the same Session-Id. > > > > > > > > 3. Accounting servers should be able to match the FA accounting > > > > records to the HA accounting records for a given MN. > > > > > > > > 4. AAAH Diameter Servers need not be session stateful. The protocol > > > > should work the same way whether Diameter Servers are session > > > > stateful or not. > > > > > > > > 5. A domain should be able to have more than one Diameter Server > > > > fulfilling the AAAH role. > > > > > > > > > > > > The following are the general principles governing HA sessions. The > > > > first two principles exist today. I am merely restating them to > > > > emphasize that I am not changing them. > > > > > > > > 1. An HA session begins when a Diameter Server sends an HAR command > > > > to an HA and receives an HAA command in response. > > > > > > > > 2. An HA session should normally end when an HA sends an STR command > > > > to a Diameter Server and receives an STA command in response. > > > > > > > > Discussion: > > > > > > > > When an AAAH receives an STR command from an AAAF for an FA > > > > session, it does not attempt to terminate the corresponding HA > > > > session by sending an ASR command. The HA will find out via > > > > the Mobile IP protocol that the session has ended and will send > > > > and STR to the AAAH. It is important to maintain this > > > > principle because the AAAH may not be aware of a pending > > > > handoff. If the HA were to terminate a session before > > > > commencing a new session for the pending handoff, the > > > > multi-session would terminate and the handoff would then fail. > > > > > > > > 3. When an AAAH receives an AMR command that represents a new FA > > > > session -- whether for a new multi-session or for a handoff within > > > > an existing multi-session -- it generates an HAR command with a > > > > new Session-Id. > > > > > > > > 4. When an HA receives an HAR command for a new session within a > > > > multi-session, it generates an HAA in response and also generates > > > > an ACR command with Accounting-Record-Type of START_RECORD. > > > > > > > > 5. When an HA terminates a session within a multi-session, it > > > > generates an STR command and also generates an ACR command with > > > > Accounting-Record-Type of STOP_RECORD. > > > > > > > > Principle number 3, above, cannot be implemented without a slight > > > > protocol change. First of all, I don't know that there is any way that > > > > a non-stateful AAAH can distinguish an AMR for a new session from a > > > > reauth AMR for an existing session. Furthermore, for a reauth, the AAAH > > > > must include the Session-Id in the HAR that identifies the > > > > reauthenticated/reauthorized session. If the AAAH is stateless, it has > > > > no way of knowing what Session-Id to use. Similarly if the AMR for the > > > > reauth is sent to a different AAAH, the second AAAH will not know what > > > > Session-Id to use in the HAR. In both of these cases, this problem is > > > > currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER > > > > PROTOCOL. In both of these cases, the AAAH generates a new value for > > > > the Session-Id. The HA cannot rely on the Session-Id in a reauth HAR to > > > > identify the session being reauthenticated/reauthorized. It must find > > > > the session some other way. > > > > > > > > In order to fix the Diameter-MobileIPv4 protocol so that it works > > > > correctly, I propose to define two new AVPs: > > > > > > > > FA-Session-Id > > > > > > > > This AVP is inserted in HAR commands by the AAAH to indicate the > > > > Session-Id of the corresponding FA session. It is inserted in ACR > > > > commands along with the MIP-Foreign-Agent-Host AVP by the HA to > > > > identify the corresponding FA session to the accounting server. > > > > > > > > HA-Session-Id > > > > > > > > This AVP is inserted in AMA commands by the AAAH to indicate the > > > > Session-Id of the corresponding HA session. It is inserted in > > > > subsequent AMR commands for the same session by the FA. When > > > > generating a HAR command, if the corresponding AMR command > > > > contains an HA-Session-Id AVP, then the AAAH includes the value of > > > > the HA-Session-Id AVP in the Session-Id AVP it inserts in the HAR. > > > > Otherwise it generates a new value for the Session-Id it inserts > > > > in the HAR. The FA also inserts the HA-Session-Id AVP in ACR > > > > commands to identify the corresponding HA session to the > > > > accounting server. > > > > > > > > This proposal requires no changes to the base protocol except to remove the > > > > following stipulation that may have been added in an earlier attempt to > > > > resolve issue 336: > > > > > > > > Accounting messages MAY use a different Session-Id from that sent in > > > > authorization messages. Specific applications MAY require different > > > > a Session-ID for accounting messages. > > > > > > > > -- > > > > David Spence email: DSpence@Interlinknetworks.com > > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > > Ann Arbor, MI 48108 > > > > U.S.A. > > > > -- > > David Spence email: DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: +1 734 821 1203 > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > Ann Arbor, MI 48108 > > U.S.A. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Mon Jun 10 10:44: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 KAA06561 for ; Mon, 10 Jun 2002 10:44:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1423A9124E; Mon, 10 Jun 2002 10:44:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5EFF9124F; Mon, 10 Jun 2002 10:44: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 E65499124E for ; Mon, 10 Jun 2002 10:44:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3BF75DE0B; Mon, 10 Jun 2002 10:44:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BD8535DD97 for ; Mon, 10 Jun 2002 10:44:29 -0400 (EDT) Received: from Interlinknetworks.com (3com1a71.rc.net [152.160.53.71]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 8E9C57B; Mon, 10 Jun 2002 10:44:34 -0400 (EDT) Message-ID: <3D04BB9A.4FBCC1E5@Interlinknetworks.com> Date: Mon, 10 Jun 2002 10:45:46 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fredrik Johansson Cc: Tony Johansson , john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik, See comments inline. Fredrik Johansson wrote: > > David, > > Please see comments below > > /Fredrik > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > David Spence > > Sent: den 8 juni 2002 22:15 > > To: Tony Johansson > > Cc: john.loughney@nokia.com; johanj@ipunplugged.com; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and > > accounting sessions > > > > > > Tony, > > > > First of all, I am not sure that I do agree that an AAAH cannot be > > stateless. Our initial implementation of a Diameter server was stateless > > and at the time we thought that we could correctly implement the > > protocol. > > I am not aware of any reason other than this issue that would prevent an > > AAAH from being session stateless. If you know of any, I would very much > > appreciate it if you would let me know. > > > > But let's suppose that we did require an AAAH to be session stateful. In > > that case, would you also require that if a domain ran multiple > > AAAH's, then > > they would be required to implement a proprietary mechanism to share state > > with each other? If not, then you would have a problem if an original > > authorization were handled by AAAH1 and a subsequent reauth were > > handled by > > AAAH2. The problem would be that AAAH2 would not know what Session-Id to > > put in the HAR. > > That's why the HA must handle the case where it receives different session > id's for the same session. The HA must recognize that it's the same session > (using MN Address, HA address and NAI), it must then return the > multi-session id to the new AAAH in order to maintain the original > multisession. No. It is true that the HA must recognize that it's the same *multi-session* using MN Address, HA address and NAI in the case where a new session is being created in the multi-session. But a reauth of an FA session does not change the FA Session-Id. It *should not* change the HA Session-Id either. And it *should not* be necessary for the HA to match on any field other than Session-Id when handling a reauth. > > > > > So let's further suppose that if multiple AAAH's exist in a > > domain they MUST > > be able to access each other's session state database. In that case, I > > think that simply deleting the last sentence ("Otherwise, if the AAAH is > > session-stateless, it will manufacture a unique session-id for every HAR") > > would technically suffice. I would probably want to strengthen the last > > phrase of the preceding sentence ("on behalf of a given mobile node's > > session"), however, to make it clear that "session" means session and not > > multi-session. That is, if an AAAH sends an HAR for a handoff of a mobile > > node's session (where the AMR that triggers it bears a different > > Session-Id > > from the AMR that produced the previous HAR), then the AAAH MUST > > generate a > > new Session-Id for the new HAR. Of course, a stateful AAAH would > > be able to > > do that. > > > > I think, however, that creating the two AVPs I defined below is > > all that is > > needed both to alleviate the AAAH from having to be stateful and to allow > > multiple AAAH's in a domain not to have to share state. Defining > > these two > > AVPs has the added benefit of helping an accounting server to match FA > > accounting records to HA accounting records for corresponding sessions. > > > > Dave > > > > Tony Johansson wrote: > > > > > > Hello David, > > > > > > I'm sorry that I haven't replied earlier. > > > > > > Before I start to comment on your proposal below. I think we > > really have to > > > start by looking at how we define a stateless versus stateful > > Diameter agent in > > > the Base protocol. > > > > > > Looking at section 2.8 Role of Diameter Agents, the following > > are stated : > > > > > > ".... > > > > > > The Diameter protocol requires that agents maintain transaction > > > state, which is used for failover purposes. Transaction state implies > > > that upon forwarding a request, its Hop-by-Hop identifier is saved; > > > the field is replaced with a locally unique identifier, which is > > > restored to its original value when the corresponding answer is > > > received. The request's state is released upon receipt of the answer. > > > A stateless agent is one that only maintains transaction state. > > > ... > > > > > > A stateful agent is one that maintains session state information; by > > > keeping track of all authorized active sessions. Each authorized > > > session is bound to a particular service, and its state is considered > > > active either until it is notified otherwise, or by expiration. Each > > > authorized session has an expiration, which is communicated by > > > Diameter servers via the Session-Timeout AVP. > > > ...." > > > > > > So, given the above, where it is clearly stated that a > > "stateless agent is one > > > that only maintains transaction state", can we really claim > > that a AAAH can be > > > stateless? If we both agree that the AAAH can not be stateless > > according to this > > > protocol definition, then just have to remove the last sentence from the > > > following paragraph on page 10 in MIP-10: > > > > > > " > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see Figure 2). If the > > > AAAH is session-stateful, it MUST send the same session identifier > > > for all HARs initiated on behalf of a given mobile node's session. > > > Otherwise, if the AAAH is session-stateless, it will manufacture a > > > unique session-id for every HAR. " > > > > > > Regards, > > > > > > /Tony > > > > > > David Spence wrote: > > > > > > > Without attempting to go through all the scenarios or draft > > all the text > > > > to be added to mobileip-10, here is my proposal for how to > > resolve issue > > > > 336 (Clarify relationship between auth and accounting sessions) in a > > > > good way. > > > > > > > > These are my goals: > > > > > > > > 1. Create a one-to-one correspondence between FA sessions and HA > > > > sessions so that for each FA session there will be a single HA > > > > session for the same MN that starts and ends at > > approximately the > > > > same time as the FA session it corresponds to. > > > > > > > > 2. Diameter MobileIPv4 accounting sessions should exactly match the > > > > authorization sessions and have the same Session-Id. > > > > > > > > 3. Accounting servers should be able to match the FA accounting > > > > records to the HA accounting records for a given MN. > > > > > > > > 4. AAAH Diameter Servers need not be session stateful. > > The protocol > > > > should work the same way whether Diameter Servers are session > > > > stateful or not. > > > > > > > > 5. A domain should be able to have more than one Diameter Server > > > > fulfilling the AAAH role. > > > > > > > > > > > > The following are the general principles governing HA sessions. The > > > > first two principles exist today. I am merely restating them to > > > > emphasize that I am not changing them. > > > > > > > > 1. An HA session begins when a Diameter Server sends an HAR command > > > > to an HA and receives an HAA command in response. > > > > > > > > 2. An HA session should normally end when an HA sends an > > STR command > > > > to a Diameter Server and receives an STA command in response. > > > > > > > > Discussion: > > > > > > > > When an AAAH receives an STR command from an AAAF for an FA > > > > session, it does not attempt to terminate the > > corresponding HA > > > > session by sending an ASR command. The HA will find out via > > > > the Mobile IP protocol that the session has ended > > and will send > > > > and STR to the AAAH. It is important to maintain this > > > > principle because the AAAH may not be aware of a pending > > > > handoff. If the HA were to terminate a session before > > > > commencing a new session for the pending handoff, the > > > > multi-session would terminate and the handoff would > > then fail. > > > > > > > > 3. When an AAAH receives an AMR command that represents a new FA > > > > session -- whether for a new multi-session or for a > > handoff within > > > > an existing multi-session -- it generates an HAR command with a > > > > new Session-Id. > > > > > > > > 4. When an HA receives an HAR command for a new session within a > > > > multi-session, it generates an HAA in response and also > > generates > > > > an ACR command with Accounting-Record-Type of START_RECORD. > > > > > > > > 5. When an HA terminates a session within a multi-session, it > > > > generates an STR command and also generates an ACR command with > > > > Accounting-Record-Type of STOP_RECORD. > > > > > > > > Principle number 3, above, cannot be implemented without a slight > > > > protocol change. First of all, I don't know that there is > > any way that > > > > a non-stateful AAAH can distinguish an AMR for a new session from a > > > > reauth AMR for an existing session. Furthermore, for a > > reauth, the AAAH > > > > must include the Session-Id in the HAR that identifies the > > > > reauthenticated/reauthorized session. If the AAAH is > > stateless, it has > > > > no way of knowing what Session-Id to use. Similarly if the > > AMR for the > > > > reauth is sent to a different AAAH, the second AAAH will not know what > > > > Session-Id to use in the HAR. In both of these cases, this problem is > > > > currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER > > > > PROTOCOL. In both of these cases, the AAAH generates a new value for > > > > the Session-Id. The HA cannot rely on the Session-Id in a > > reauth HAR to > > > > identify the session being reauthenticated/reauthorized. It must find > > > > the session some other way. > > > > > > > > In order to fix the Diameter-MobileIPv4 protocol so that it works > > > > correctly, I propose to define two new AVPs: > > > > > > > > FA-Session-Id > > > > > > > > This AVP is inserted in HAR commands by the AAAH to indicate the > > > > Session-Id of the corresponding FA session. It is > > inserted in ACR > > > > commands along with the MIP-Foreign-Agent-Host AVP by the HA to > > > > identify the corresponding FA session to the accounting server. > > > > > > > > HA-Session-Id > > > > > > > > This AVP is inserted in AMA commands by the AAAH to indicate the > > > > Session-Id of the corresponding HA session. It is inserted in > > > > subsequent AMR commands for the same session by the FA. When > > > > generating a HAR command, if the corresponding AMR command > > > > contains an HA-Session-Id AVP, then the AAAH includes > > the value of > > > > the HA-Session-Id AVP in the Session-Id AVP it inserts > > in the HAR. > > > > Otherwise it generates a new value for the Session-Id it inserts > > > > in the HAR. The FA also inserts the HA-Session-Id AVP in ACR > > > > commands to identify the corresponding HA session to the > > > > accounting server. > > > > > > > > This proposal requires no changes to the base protocol except > > to remove the > > > > following stipulation that may have been added in an earlier > > attempt to > > > > resolve issue 336: > > > > > > > > Accounting messages MAY use a different Session-Id from > > that sent in > > > > authorization messages. Specific applications MAY require > > different > > > > a Session-ID for accounting messages. > > > > > > > > -- > > > > David Spence email: > > DSpence@Interlinknetworks.com > > > > Interlink Networks, Inc. phone: +1 734 821 1203 > > > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > > > Ann Arbor, MI 48108 > > > > U.S.A. > > > > -- > > David Spence email: > > DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: +1 734 821 1203 > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > Ann Arbor, MI 48108 > > U.S.A. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Mon Jun 10 14:42:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18429 for ; Mon, 10 Jun 2002 14:42:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D1F7D91263; Mon, 10 Jun 2002 14:42:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B8E291264; Mon, 10 Jun 2002 14:42:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 896FA91263 for ; Mon, 10 Jun 2002 14:42:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 825155DE0B; Mon, 10 Jun 2002 14:42:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by segue.merit.edu (Postfix) with ESMTP id 05F355DD8F for ; Mon, 10 Jun 2002 14:42:10 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5AIgAo12707; Mon, 10 Jun 2002 14:42:10 -0400 (EDT) Received: from mccap-1.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA29936; Mon, 10 Jun 2002 13:42:09 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GXI6M8-0000Z4-00; Mon, 10 Jun 2002 14:42:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15620.62207.198167.629456@gargle.gargle.HOWL> Date: Mon, 10 Jun 2002 13:42:07 -0500 From: Pete McCann To: Cc: , , Subject: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E48@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E48@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 Hi, As I understand it 3GPP is currently planning to define several 3GPP-specific Diameter applications. These include their Cx interface, for SIP authentication/authorization, the Sh interface, for SIP application authentication/authorization, and the Charging application for IMS. I believe they plan to make extensive use of 3GPP-specific Vendor/Organization codes in these applications, and to proceed on these applications without standards action in the IETF. Removing vendor-specific support from the Diameter base protocol would be quite disruptive to these plans. -Pete john.loughney@nokia.com writes: > Hi all, > > If I have understood Randy Bush correctly, the IESG strongly > objects to the inclusion of support for vendor-specific command-codes > in the Diameter Base Protocol. > > The modifications needed to remove these are as follows: > > 1) removal of Vendor-ID from the Diameter Header. > 2) removal vendor-specific command-codes from 5.3.6 > 3) vendor-specific Diameter command-codes from 6.11 > 4) Discussion of vendor-specific Diameter command-codes in section 11.2.1 > > Below is the current text from Diameter 11 that discusses vendor-specific command-codes. > > Again, the proposal is that all mention of vendor-specific command-codes > would be removed. > > Please comment on the list. > > thanks, > John > > ============ > > 3 Diameter Header > > [text clipped] > > Vendor-ID > 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" > [ASSIGNNO] 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 vendor's vendor-specific command, nor with > future IETF applications. All vendor-specific Diameter commands > require Informational RFCs documenting the command unless for > Private Use as described in Section 11.1.1. > > -> (11.1.1 needs to be changed to 11.2.1) > > ===== > > 5.3.6 Supported-Vendor-Id AVP > > The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise Codes" > [ASSIGNNO] value assigned to a vendor other than the device vendor. > This is used in the CER and CEA messages in order to inform the peer > that the sender supports a subset of the vendor-specific commands > and/or AVPs defined by the vendor identified in this AVP. > > ===== > > 6.11 Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present. > > This AVP MUST also be present in all vendor-specific commands defined > in the vendor-specific application. > > This AVP SHOULD be placed as close to the Diameter header as > possible. > > AVP Format > > ::= < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > ===== > > > 11.2.1 Command Codes > > The Command Code namespace is used to identify Diameter commands. The > values 0-255 are reserved for RADIUS backward compatibility, and are > defined as "RADIUS Packet Type Codes" in [RADTYPE]. The remaining > values are available via Standards Action [IANA]. > > Vendor-Specific Command Codes, where the Vendor-Id field in the > Diameter header is set to a non-zero value, are for Private Use. From owner-aaa-wg@merit.edu Mon Jun 10 15:32: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 PAA21168 for ; Mon, 10 Jun 2002 15:32:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3AF3491264; Mon, 10 Jun 2002 15:31:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4AB49126A; Mon, 10 Jun 2002 15:31: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 97BFE91264 for ; Mon, 10 Jun 2002 15:31:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 823175DE0B; Mon, 10 Jun 2002 15:31:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 33EAD5DDFE for ; Mon, 10 Jun 2002 15:31:32 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5AJVde25116; Mon, 10 Jun 2002 15:31:39 -0400 (EDT) Received: from new-wopr.eng.ascend.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id PAA14910 for ; Mon, 10 Jun 2002 15:31:37 -0400 (EDT) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by new-wopr.eng.ascend.com (8.10.2+Sun/8.10.2) with ESMTP id g5AJVZq29611; Mon, 10 Jun 2002 12:31:35 -0700 (PDT) Received: from igoyret-pc by grigri.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id MAA15428; Mon, 10 Jun 2002 12:31:34 -0700 (PDT) Message-Id: <3.0.5.32.20020610123003.03c81100@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 10 Jun 2002 12:30:03 -0700 To: Randy Bush From: Ignacio Goyret Subject: Re: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts Cc: Bernard Aboba , aaa-wg@merit.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk At 09:32 PM 6/8/02 -0700, Randy Bush wrote: > >as ad, i will not be passing this to the iesg for review. there >is one comment that has not been addressed by -11, vendor-specific >commands. as i have repeatedly said, if i was to pass this to the >iesg, it is a sure show-stopper. > >rather than saying it all over again, can folk please review the >mailing list archive on this. essentially, the iesg has a hot- >button about mandatory vendor commands. If that is true, it seems to me the IESG needs to get a big dose of reality check. A fact of life is that the IETF and just about every other standard body moves ever so slowly that vendors are forced to add vendor specific extensions to satisfy their clients. Often, those extensions become de-facto "standards". Now, would you prefer those extension mechanisms to be ad-hoc, where interoperability will probably be an issue or would you prefer that vendor extension mechanisms be defined up front in a way that guarantees interoperability? From owner-aaa-wg@merit.edu Mon Jun 10 15:35: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 PAA21305 for ; Mon, 10 Jun 2002 15:35:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E625B91266; Mon, 10 Jun 2002 15:35:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A44A591265; Mon, 10 Jun 2002 15:35: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 C93EA91267 for ; Mon, 10 Jun 2002 15:35:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B52F95DE63; Mon, 10 Jun 2002 15:35:08 -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 693C55DDFE for ; Mon, 10 Jun 2002 15:35:08 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 12:35:16 -0700 Message-ID: From: "Pat R. Calhoun" To: "'Ignacio Goyret'" , Randy Bush Cc: Bernard Aboba , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans port-07 drafts Date: Mon, 10 Jun 2002 12:35:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C210B5.EF206D80" 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_01C210B5.EF206D80 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Certainly we have existence proof of what Ignacio describes below with the RADIUS protocol. Not necessarily something we want to duplicate. Perhaps we can better understand the concerns so that we can react better than just scrapping a major feature. PatC - -----Original Message----- From: Ignacio Goyret [mailto:igoyret@lucent.com] Sent: Monday, June 10, 2002 12:30 PM To: Randy Bush Cc: Bernard Aboba; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts At 09:32 PM 6/8/02 -0700, Randy Bush wrote: > >as ad, i will not be passing this to the iesg for review. there is >one comment that has not been addressed by -11, vendor-specific >commands. as i have repeatedly said, if i was to pass this to the >iesg, it is a sure show-stopper. > >rather than saying it all over again, can folk please review the >mailing list archive on this. essentially, the iesg has a hot- >button about mandatory vendor commands. If that is true, it seems to me the IESG needs to get a big dose of reality check. A fact of life is that the IETF and just about every other standard body moves ever so slowly that vendors are forced to add vendor specific extensions to satisfy their clients. Often, those extensions become de-facto "standards". Now, would you prefer those extension mechanisms to be ad-hoc, where interoperability will probably be an issue or would you prefer that vendor extension mechanisms be defined up front in a way that guarantees interoperability? -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPQT/bjN1fXKoxmisEQJeBACgqUEO7luLKyVnaxWYl0nziKPO8kwAn0jr rVdG+9ZebyCrzZOpI2ZfeaP5 =SOz+ -----END PGP SIGNATURE----- ------_=_NextPart_001_01C210B5.EF206D80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for IETF last call on Diameter-11 and = Transport-07 drafts

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Certainly we have existence proof of what Ignacio = describes below
with the RADIUS protocol. Not necessarily something = we want to
duplicate.

Perhaps we can better understand the concerns so that = we can react
better than just scrapping a major feature.

PatC

- -----Original Message-----
From: Ignacio Goyret [mailto:igoyret@lucent.com] =
Sent: Monday, June 10, 2002 12:30 PM
To: Randy Bush
Cc: Bernard Aboba; aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Request for IETF last call on = Diameter-11 and
Transport-07 drafts


At 09:32 PM 6/8/02 -0700, Randy Bush wrote:
>
>as ad, i will not be passing this to the iesg = for review.  there is
>one  comment that has not been addressed by = -11, vendor-specific
>commands.   as i have repeatedly said, = if i was to pass this to the
>iesg, it is a  sure show-stopper.
>
>rather than saying it all over again, can folk = please review the
>mailing list archive on this.  essentially, = the iesg has a hot-
>button  about mandatory vendor = commands.

If that is true, it seems to me the IESG needs to get = a big dose of
reality check. A fact of life is that the IETF and = just about every
other standard body moves ever so slowly that = vendors are forced to
add vendor specific extensions to satisfy their = clients. Often, those
extensions become de-facto = "standards".

Now, would you prefer those extension mechanisms to = be ad-hoc, where
interoperability will probably be an issue or would = you prefer that
vendor extension mechanisms be defined up front in a = way that
guarantees interoperability?

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPQT/bjN1fXKoxmisEQJeBACgqUEO7luLKyVnaxWYl0nziKPO8kwAn0j= r
rVdG+9ZebyCrzZOpI2ZfeaP5
=3DSOz+
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C210B5.EF206D80-- From owner-aaa-wg@merit.edu Mon Jun 10 15:39: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 PAA21570 for ; Mon, 10 Jun 2002 15:39:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E99C9126A; Mon, 10 Jun 2002 15:37:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1F139126B; Mon, 10 Jun 2002 15:37: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 89A4C9126A for ; Mon, 10 Jun 2002 15:37:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 770F75DE63; Mon, 10 Jun 2002 15:37:36 -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 A57DF5DDFE for ; Mon, 10 Jun 2002 15:37:35 -0400 (EDT) Received: (qmail 6384 invoked by uid 500); 10 Jun 2002 19:37:44 -0000 Date: Mon, 10 Jun 2002 14:37:43 -0500 From: David Frascone To: Ignacio Goyret Cc: Randy Bush , Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts Message-ID: <20020610193743.GE1695@newman.frascone.com> Mail-Followup-To: Ignacio Goyret , Randy Bush , Bernard Aboba , aaa-wg@merit.edu References: <3.0.5.32.20020610123003.03c81100@grigri.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.5.32.20020610123003.03c81100@grigri.eng.ascend.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Perhaps I'm missing something here, so feel free to shoot me down, but the key word I saw in that paragraph was "mandatory" I understood his objection to mean that the Diameter protocol could now have vendor specific commands that were mandatory to support. Which, seemed like a no-brainer to me. But, then again, perhaps I'm confused :) On Monday, 10 Jun 2002, Ignacio Goyret wrote: > At 09:32 PM 6/8/02 -0700, Randy Bush wrote: > > > >as ad, i will not be passing this to the iesg for review. there > >is one comment that has not been addressed by -11, vendor-specific > >commands. as i have repeatedly said, if i was to pass this to the > >iesg, it is a sure show-stopper. > > > >rather than saying it all over again, can folk please review the > >mailing list archive on this. essentially, the iesg has a hot- > >button about mandatory vendor commands. > > If that is true, it seems to me the IESG needs to get a big dose of > reality check. A fact of life is that the IETF and just about every > other standard body moves ever so slowly that vendors are forced > to add vendor specific extensions to satisfy their clients. Often, > those extensions become de-facto "standards". > > Now, would you prefer those extension mechanisms to be ad-hoc, where > interoperability will probably be an issue or would you prefer that > vendor extension mechanisms be defined up front in a way that guarantees > interoperability? > -- David Frascone Programmers don't die, they just GOSUB without RETURN. From owner-aaa-wg@merit.edu Mon Jun 10 15:42:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21776 for ; Mon, 10 Jun 2002 15:42:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 265A991267; Mon, 10 Jun 2002 15:42:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC3CF91268; Mon, 10 Jun 2002 15:42:26 -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 D407491267 for ; Mon, 10 Jun 2002 15:42:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C7BDF5DE63; Mon, 10 Jun 2002 15:42:21 -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 9ABC75DDFE for ; Mon, 10 Jun 2002 15:42:21 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AJgDD12713; Mon, 10 Jun 2002 15:42:13 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 15:42:13 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5B4@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Pat R. Calhoun'" , "'Ignacio Goyret'" , Randy Bush Cc: Bernard Aboba , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans port-07 drafts Date: Mon, 10 Jun 2002 15:42:04 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-aaa-wg@merit.edu Precedence: bulk Based on the summary of Randy's concerns presented this morning, the protocol mechanisms for extensibility are not the issue. The issue is that the document must state a requirement that extensions be publicly documented. Probably the form of that documentation will be required to be an IETF Informational RFC, analogous to the SIP P-Header process now being tested in the SIP WG. -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Monday, June 10, 2002 3:35 PM To: 'Ignacio Goyret'; Randy Bush Cc: Bernard Aboba; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans port-07 drafts -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Certainly we have existence proof of what Ignacio describes below with the RADIUS protocol. Not necessarily something we want to duplicate. Perhaps we can better understand the concerns so that we can react better than just scrapping a major feature. PatC - -----Original Message----- From: Ignacio Goyret [mailto:igoyret@lucent.com] Sent: Monday, June 10, 2002 12:30 PM To: Randy Bush Cc: Bernard Aboba; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts At 09:32 PM 6/8/02 -0700, Randy Bush wrote: > >as ad, i will not be passing this to the iesg for review. there is >one comment that has not been addressed by -11, vendor-specific >commands. as i have repeatedly said, if i was to pass this to the >iesg, it is a sure show-stopper. > >rather than saying it all over again, can folk please review the >mailing list archive on this. essentially, the iesg has a hot- >button about mandatory vendor commands. If that is true, it seems to me the IESG needs to get a big dose of reality check. A fact of life is that the IETF and just about every other standard body moves ever so slowly that vendors are forced to add vendor specific extensions to satisfy their clients. Often, those extensions become de-facto "standards". Now, would you prefer those extension mechanisms to be ad-hoc, where interoperability will probably be an issue or would you prefer that vendor extension mechanisms be defined up front in a way that guarantees interoperability? -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPQT/bjN1fXKoxmisEQJeBACgqUEO7luLKyVnaxWYl0nziKPO8kwAn0jr rVdG+9ZebyCrzZOpI2ZfeaP5 =SOz+ -----END PGP SIGNATURE----- From owner-aaa-wg@merit.edu Mon Jun 10 15:57: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 PAA22559 for ; Mon, 10 Jun 2002 15:57:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 247A09126B; Mon, 10 Jun 2002 15:58:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC6BB9126C; Mon, 10 Jun 2002 15:58:06 -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 E46409126B for ; Mon, 10 Jun 2002 15:58:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D5C265DDDD; Mon, 10 Jun 2002 15:58:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (dhcp3202.nanog25.merit.net [192.35.167.202]) by segue.merit.edu (Postfix) with ESMTP id B4F755DDB1 for ; Mon, 10 Jun 2002 15:58:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HVIn-0001uZ-00 for aaa-wg@merit.edu; Mon, 10 Jun 2002 12:58:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans port-07 drafts References: <4D79C746863DD51197690002A52CDA0001E8A5B4@zcard0kc.ca.nortel.com> Message-Id: Date: Mon, 10 Jun 2002 12:58:09 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit it's two things in general, extensions need ietf process. and, non-standard extensions can not be mandatory. e.g. when dynamic negotiation over an extension fails, the fault must clearly be with the side demanding the extension, not the side not implementing it. randy From owner-aaa-wg@merit.edu Mon Jun 10 16:19: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 QAA23392 for ; Mon, 10 Jun 2002 16:19:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D4DC79121E; Mon, 10 Jun 2002 16:19:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EC1691227; Mon, 10 Jun 2002 16:19:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACD079121E for ; Mon, 10 Jun 2002 16:19:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F6975DDAA; Mon, 10 Jun 2002 16:19:16 -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 275A25DD8D for ; Mon, 10 Jun 2002 16:19:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5AJTqn02752; Mon, 10 Jun 2002 12:29:52 -0700 Date: Mon, 10 Jun 2002 12:29:52 -0700 (PDT) From: Bernard Aboba To: David Frascone Cc: Randy Bush , Subject: Re: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts In-Reply-To: <20020610193743.GE1695@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Perhaps I'm missing something here, so feel free to shoot me down, but the > key word I saw in that paragraph was "mandatory" > > I understood his objection to mean that the Diameter protocol could not > have vendor specific commands that were mandatory to support. Which, > seemed like a no-brainer to me. > > But, then again, perhaps I'm confused :) I think that the question relates to how vendors can extend Diameter while still retaining the ability to fall back to standardized capabilities if one of the peers does not support the extension. This is already possible with Vendor-Specific non-mandatory AVPs. If a peer doesn't understand these, then they can ignore them. For mandatory Vendor-Specific AVPs, an error results if the peer does not support them, but the fault lies with the VSA sender. Vendor-Specific Commands in Base-11 are mandatory, so a capabilities negotiation cannot conclude successfully if one of the peers does not support the VSC. That's part of the reason why Diameter-11 indicates that VSCs are a last resort. Interoperability will always be better when standardized commands are reused with Vendor-Specific AVPs than when the same functionality is implemented with vendor-specific commands. The question is whether there is a way to avoid negotiation failure with VSCs. For example, would it be possible to fall back from a VSC to use of standardized commands, perhaps with Vendor-Specific AVPs? From owner-aaa-wg@merit.edu Mon Jun 10 20:02:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29559 for ; Mon, 10 Jun 2002 20:02:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B140991212; Mon, 10 Jun 2002 20:02:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8124191227; Mon, 10 Jun 2002 20:02: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 7D06391212 for ; Mon, 10 Jun 2002 20:02:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71C2F5DDAA; Mon, 10 Jun 2002 20:02: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 E70E85DD8D for ; Mon, 10 Jun 2002 20:02:42 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user52.cisco.com [10.70.82.52]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA11681; Mon, 10 Jun 2002 17:02:08 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "David Frascone" , "Ignacio Goyret" Cc: "Randy Bush" , "Bernard Aboba" , Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts Date: Mon, 10 Jun 2002 17:01:48 -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: <20020610193743.GE1695@newman.frascone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Frascone [mailto://dave@frascone.com] writes: > Perhaps I'm missing something here, so feel free to shoot me down, but the > key word I saw in that paragraph was "mandatory" > > I understood his objection to mean that the Diameter protocol > could now have > vendor specific commands that were mandatory to support. Which, seemed > like a no-brainer to me. Sure, but I can't find anything in the draft that says that support for vendor-specific commands is recommended, let alone mandatory. > > But, then again, perhaps I'm confused :) You and me, too. > > On Monday, 10 Jun 2002, Ignacio Goyret wrote: > > At 09:32 PM 6/8/02 -0700, Randy Bush wrote: > > > > > >as ad, i will not be passing this to the iesg for review. there > > >is one comment that has not been addressed by -11, vendor-specific > > >commands. as i have repeatedly said, if i was to pass this to the > > >iesg, it is a sure show-stopper. > > > > > >rather than saying it all over again, can folk please review the > > >mailing list archive on this. essentially, the iesg has a hot- > > >button about mandatory vendor commands. > > > > If that is true, it seems to me the IESG needs to get a big dose of > > reality check. A fact of life is that the IETF and just about every > > other standard body moves ever so slowly that vendors are forced > > to add vendor specific extensions to satisfy their clients. Often, > > those extensions become de-facto "standards". > > > > Now, would you prefer those extension mechanisms to be ad-hoc, where > > interoperability will probably be an issue or would you prefer that > > vendor extension mechanisms be defined up front in a way that guarantees > > interoperability? > > > > -- > David Frascone > > Programmers don't die, they just GOSUB without RETURN. > > From owner-aaa-wg@merit.edu Mon Jun 10 22:02: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 WAA01813 for ; Mon, 10 Jun 2002 22:02:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A546991227; Mon, 10 Jun 2002 22:02:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B49991228; Mon, 10 Jun 2002 22:02:41 -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 4256391227 for ; Mon, 10 Jun 2002 22:02:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 434C85DDB0; Mon, 10 Jun 2002 22:02:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 740F15DD8D for ; Mon, 10 Jun 2002 22:02:34 -0400 (EDT) Received: from cisco.com ([10.77.201.96]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA28614; Tue, 11 Jun 2002 07:31:07 +0530 (IST) Message-ID: <3D055A2E.6BC8AE7@cisco.com> Date: Tue, 11 Jun 2002 07:32:22 +0530 From: Sakthidaran V X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, randy@psg.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E48@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John , But , that is not MANDATORY in the existing draft (draft-10) . Is it ? I heard mentions of Sections 5.3.3 and 5.3.6 . The references in Section 6.10 have been mentioned as 6.11 in your mail I guess it is a typo . 6.10 Vendor-Specific-Application-Id AVP The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Either the Auth-Application-Id or the Acct- Application-Id AVP MAY be present. Exactly one of the Auth- Application-Id and Acct-Application-Id AVPs MAY be present. This AVP MUST also be present in all vendor-specific commands defined in the vendor-specific application. This AVP SHOULD be placed as close to the Diameter header as possible. AVP Format ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } Regds Shakthi svadakey@cisco.com john.loughney@nokia.com wrote: > Hi all, > > If I have understood Randy Bush correctly, the IESG strongly > objects to the inclusion of support for vendor-specific command-codes > in the Diameter Base Protocol. > > The modifications needed to remove these are as follows: > > 1) removal of Vendor-ID from the Diameter Header. > 2) removal vendor-specific command-codes from 5.3.6 > 3) vendor-specific Diameter command-codes from 6.11 > 4) Discussion of vendor-specific Diameter command-codes in section 11.2.1 > > Below is the current text from Diameter 11 that discusses vendor-specific command-codes. > > Again, the proposal is that all mention of vendor-specific command-codes > would be removed. > > Please comment on the list. > > thanks, > John > > ============ > > 3 Diameter Header > > [text clipped] > > Vendor-ID > 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" > [ASSIGNNO] 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 vendor's vendor-specific command, nor with > future IETF applications. All vendor-specific Diameter commands > require Informational RFCs documenting the command unless for > Private Use as described in Section 11.1.1. > > -> (11.1.1 needs to be changed to 11.2.1) > > ===== > > 5.3.6 Supported-Vendor-Id AVP > > The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise Codes" > [ASSIGNNO] value assigned to a vendor other than the device vendor. > This is used in the CER and CEA messages in order to inform the peer > that the sender supports a subset of the vendor-specific commands > and/or AVPs defined by the vendor identified in this AVP. > > ===== > > 6.11 Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present. > > This AVP MUST also be present in all vendor-specific commands defined > in the vendor-specific application. > > This AVP SHOULD be placed as close to the Diameter header as > possible. > > AVP Format > > ::= < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > ===== > > 11.2.1 Command Codes > > The Command Code namespace is used to identify Diameter commands. The > values 0-255 are reserved for RADIUS backward compatibility, and are > defined as "RADIUS Packet Type Codes" in [RADTYPE]. The remaining > values are available via Standards Action [IANA]. > > Vendor-Specific Command Codes, where the Vendor-Id field in the > Diameter header is set to a non-zero value, are for Private Use. -- From owner-aaa-wg@merit.edu Mon Jun 10 22:05: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 WAA01838 for ; Mon, 10 Jun 2002 22:05:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4811D91253; Mon, 10 Jun 2002 22:05:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F9AE9126D; Mon, 10 Jun 2002 22:05: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 963F991253 for ; Mon, 10 Jun 2002 22:05:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 80DDE5DDB0; Mon, 10 Jun 2002 22:05:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id E32E65DD8D for ; Mon, 10 Jun 2002 22:05:22 -0400 (EDT) Received: from cisco.com ([10.77.201.96]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA28748; Tue, 11 Jun 2002 07:33:59 +0530 (IST) Message-ID: <3D055ADA.A7EE6D3F@cisco.com> Date: Tue, 11 Jun 2002 07:35:14 +0530 From: Sakthidaran V X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, randy@psg.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E48@esebe004.NOE.Nokia.com> <3D055A2E.6BC8AE7@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit OOPS , Pls ignore I looked at Diameter-10 instead of Diameter-11 . Sorry !! But my point about it not being MANDATORY still holds right ? Thank you for your time . Regds Shakthi svadakey@cisco.com Sakthidaran V wrote: > John , > > But , that is not MANDATORY in the existing draft (draft-10) . > Is it ? > I heard mentions of Sections 5.3.3 and 5.3.6 . > The references in Section 6.10 have been mentioned as 6.11 in your mail > I guess it is a typo . > > 6.10 Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Either the Auth-Application-Id or the Acct- > Application-Id AVP MAY be present. Exactly one of the Auth- > Application-Id and Acct-Application-Id AVPs MAY be present. > > This AVP MUST also be present in all vendor-specific commands defined > in the vendor-specific application. > > This AVP SHOULD be placed as close to the Diameter header as > possible. > > AVP Format > > ::= < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > Regds > Shakthi > svadakey@cisco.com > > john.loughney@nokia.com wrote: > > > Hi all, > > > > If I have understood Randy Bush correctly, the IESG strongly > > objects to the inclusion of support for vendor-specific command-codes > > in the Diameter Base Protocol. > > > > The modifications needed to remove these are as follows: > > > > 1) removal of Vendor-ID from the Diameter Header. > > 2) removal vendor-specific command-codes from 5.3.6 > > 3) vendor-specific Diameter command-codes from 6.11 > > 4) Discussion of vendor-specific Diameter command-codes in section 11.2.1 > > > > Below is the current text from Diameter 11 that discusses vendor-specific command-codes. > > > > Again, the proposal is that all mention of vendor-specific command-codes > > would be removed. > > > > Please comment on the list. > > > > thanks, > > John > > > > ============ > > > > 3 Diameter Header > > > > [text clipped] > > > > Vendor-ID > > 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" > > [ASSIGNNO] 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 vendor's vendor-specific command, nor with > > future IETF applications. All vendor-specific Diameter commands > > require Informational RFCs documenting the command unless for > > Private Use as described in Section 11.1.1. > > > > -> (11.1.1 needs to be changed to 11.2.1) > > > > ===== > > > > 5.3.6 Supported-Vendor-Id AVP > > > > The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and > > contains the IANA "SMI Network Management Private Enterprise Codes" > > [ASSIGNNO] value assigned to a vendor other than the device vendor. > > This is used in the CER and CEA messages in order to inform the peer > > that the sender supports a subset of the vendor-specific commands > > and/or AVPs defined by the vendor identified in this AVP. > > > > ===== > > > > 6.11 Vendor-Specific-Application-Id AVP > > > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > > Grouped and is used to advertise support of a vendor-specific > > Diameter Application. Exactly one of the Auth-Application-Id and > > Acct-Application-Id AVPs MAY be present. > > > > This AVP MUST also be present in all vendor-specific commands defined > > in the vendor-specific application. > > > > This AVP SHOULD be placed as close to the Diameter header as > > possible. > > > > AVP Format > > > > ::= < AVP Header: 260 > > > 1* [ Vendor-Id ] > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > > > ===== > > > > 11.2.1 Command Codes > > > > The Command Code namespace is used to identify Diameter commands. The > > values 0-255 are reserved for RADIUS backward compatibility, and are > > defined as "RADIUS Packet Type Codes" in [RADTYPE]. The remaining > > values are available via Standards Action [IANA]. > > > > Vendor-Specific Command Codes, where the Vendor-Id field in the > > Diameter header is set to a non-zero value, are for Private Use. > > -- -- From owner-aaa-wg@merit.edu Mon Jun 10 23:10: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 XAA02967 for ; Mon, 10 Jun 2002 23:10:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C12F91228; Mon, 10 Jun 2002 23:10:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27E769126D; Mon, 10 Jun 2002 23:10:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 179BE91228 for ; Mon, 10 Jun 2002 23:10:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 158285DDB0; Mon, 10 Jun 2002 23:10:17 -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 6E8FD5DD98 for ; Mon, 10 Jun 2002 23:10:16 -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 g5B3C5W24761 for ; Tue, 11 Jun 2002 06:12:05 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 06:10:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 06:10: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-8859-1" Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans port-07 drafts Date: Tue, 11 Jun 2002 06:10:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E4A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for IETF last call on Diameter-11 and Trans port-07 drafts Thread-Index: AcIQuTIVgie15AnhR6isUoM3UWHIXAAO4eFQ From: To: , X-OriginalArrivalTime: 11 Jun 2002 03:10:24.0314 (UTC) FILETIME=[875239A0:01C210F5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA02967 Hi Randy, > it's two things > > in general, extensions need ietf process. > > and, non-standard extensions can not be mandatory. e.g. when dynamic > negotiation over an extension fails, the fault must clearly be with > the side demanding the extension, not the side not implementing it. For vendor-specific commands, should I add text which states that 1) IETF Process is needed 2) Documentation needs to provide mechanism so that communication with Diameter peers without the said vendor-specific command is still possible. (e.g. when dynamic negotiation over an extension fails, the fault must clearly be with the side demanding the extension, not the side not implementing it.) Is this enough? John From owner-aaa-wg@merit.edu Tue Jun 11 01:59: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 BAA05429 for ; Tue, 11 Jun 2002 01:59:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6CD491232; Tue, 11 Jun 2002 01:52:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90D0C91234; Tue, 11 Jun 2002 01:52:46 -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 849DB91232 for ; Tue, 11 Jun 2002 01:52:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8582A5DD99; Tue, 11 Jun 2002 01:52:41 -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 DB46D5DD8D for ; Tue, 11 Jun 2002 01:52:40 -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 g5B5rFi09005 for ; Tue, 11 Jun 2002 08:53:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 08:52:48 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 08:52:48 +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]: Issue: Removal of vendor-specific Diameter command-codes Date: Tue, 11 Jun 2002 08:52:47 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653CF@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes Thread-Index: AcIQ7HAIjivOjyLlRv2B0g1DOwE94wAH5WGg From: To: Cc: , , X-OriginalArrivalTime: 11 Jun 2002 05:52:48.0374 (UTC) FILETIME=[373BC960:01C2110C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA05429 Hi Shakthi, > I looked at Diameter-10 instead of Diameter-11 . > > Sorry !! > > But my point about it not being MANDATORY still holds right ? The issue is how to 'standardize' a new vendor command. What affects does it have on existing implementations, etc. What is needed is some language in the base spec that says that if vendor commands are used, they MUST NOT cause interoperability problems with existing implementations. John From owner-aaa-wg@merit.edu Tue Jun 11 02:54: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 CAA14716 for ; Tue, 11 Jun 2002 02:54:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6841F91234; Tue, 11 Jun 2002 02:54:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31F839123D; Tue, 11 Jun 2002 02:54:26 -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 1DAB991234 for ; Tue, 11 Jun 2002 02:54:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 233335DD9E; Tue, 11 Jun 2002 02:54:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 5F4FE5DD8D for ; Tue, 11 Jun 2002 02:54:19 -0400 (EDT) Received: from cisco.com ([10.77.201.96]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA27412; Tue, 11 Jun 2002 12:22:55 +0530 (IST) Message-ID: <3D059E91.75ABA154@cisco.com> Date: Tue, 11 Jun 2002 12:24:09 +0530 From: Sakthidaran V X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, randy@psg.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653CF@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John , Thanks for helping me to understand . In the event that we can try to have a seperate draft addressing Vendor Specific Command Codes and remove these references from the base protocol and the Vendor Specific Command draft should be "ON TOP OF" the base protocol that DOES NOT have these . How does this sound ? (A Newbie may be wrong !! Newbie -->Me ) Thank you for your time . Regds Shakthi svadakey@cisco.com john.loughney@nokia.com wrote: > Hi Shakthi, > > > I looked at Diameter-10 instead of Diameter-11 . > > > > Sorry !! > > > > But my point about it not being MANDATORY still holds right ? > > The issue is how to 'standardize' a new vendor command. What > affects does it have on existing implementations, etc. > > What is needed is some language in the base spec that says that > if vendor commands are used, they MUST NOT cause interoperability > problems with existing implementations. > > John -- From owner-aaa-wg@merit.edu Tue Jun 11 03:05: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 DAA14900 for ; Tue, 11 Jun 2002 03:05:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1D7789123D; Tue, 11 Jun 2002 03:05:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 761FE91270; Tue, 11 Jun 2002 03:05:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 132A09123D for ; Tue, 11 Jun 2002 03:05:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FE035DD9E; Tue, 11 Jun 2002 03:05:27 -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 844ED5DD8D for ; Tue, 11 Jun 2002 03:05: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 g5B761i00980 for ; Tue, 11 Jun 2002 10:06:01 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 10:05:34 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 10:05:34 +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]: Issue: Removal of vendor-specific Diameter command-codes Date: Tue, 11 Jun 2002 10:05:33 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E424B@esebe016.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes Thread-Index: AcIQrppS5HcFoJSvSCG175kBQWed7gAZqMRg From: To: , Cc: , , X-OriginalArrivalTime: 11 Jun 2002 07:05:34.0447 (UTC) FILETIME=[619DA7F0:01C21116] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA14900 Hi, I fully support the Pete's view. In 3GPP the vendor-specific-application-Id AVP is widely used. In my understanding 3GPP has already been assigned the vendor-id 10415. Removing vendor-specific support from the Diameter base it would actually be very disruptive. BR Marco > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 10. June 2002 21:42 > To: Loughney John (NRC/Helsinki) > Cc: aboba@internaut.com; randy@psg.com; aaa-wg@merit.edu > Subject: [AAA-WG]: Issue: Removal of vendor-specific Diameter > command-codes > > > > Hi, > > As I understand it 3GPP is currently planning to define several > 3GPP-specific Diameter applications. These include their Cx > interface, for SIP authentication/authorization, the Sh interface, for > SIP application authentication/authorization, and the Charging > application for IMS. I believe they plan to make extensive use of > 3GPP-specific Vendor/Organization codes in these applications, and to > proceed on these applications without standards action in the IETF. > Removing vendor-specific support from the Diameter base protocol would > be quite disruptive to these plans. > > -Pete > > john.loughney@nokia.com writes: > > Hi all, > > > > If I have understood Randy Bush correctly, the IESG strongly > > objects to the inclusion of support for vendor-specific > command-codes > > in the Diameter Base Protocol. > > > > The modifications needed to remove these are as follows: > > > > 1) removal of Vendor-ID from the Diameter Header. > > 2) removal vendor-specific command-codes from 5.3.6 > > 3) vendor-specific Diameter command-codes from 6.11 > > 4) Discussion of vendor-specific Diameter command-codes in > section 11.2.1 > > > > Below is the current text from Diameter 11 that discusses > vendor-specific command-codes. > > > > Again, the proposal is that all mention of vendor-specific > command-codes > > would be removed. > > > > Please comment on the list. > > > > thanks, > > John > > > > ============ > > > > 3 Diameter Header > > > > [text clipped] > > > > Vendor-ID > > 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" > > [ASSIGNNO] 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 vendor's vendor-specific > command, nor with > > future IETF applications. All vendor-specific > Diameter commands > > require Informational RFCs documenting the command unless for > > Private Use as described in Section 11.1.1. > > > > -> (11.1.1 needs to be changed to 11.2.1) > > > > ===== > > > > 5.3.6 Supported-Vendor-Id AVP > > > > The Supported-Vendor-Id AVP (AVP Code 265) is of type > Unsigned32 and > > contains the IANA "SMI Network Management Private > Enterprise Codes" > > [ASSIGNNO] value assigned to a vendor other than the > device vendor. > > This is used in the CER and CEA messages in order to > inform the peer > > that the sender supports a subset of the > vendor-specific commands > > and/or AVPs defined by the vendor identified in this AVP. > > > > ===== > > > > 6.11 Vendor-Specific-Application-Id AVP > > > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > > Grouped and is used to advertise support of a vendor-specific > > Diameter Application. Exactly one of the Auth-Application-Id and > > Acct-Application-Id AVPs MAY be present. > > > > This AVP MUST also be present in all vendor-specific > commands defined > > in the vendor-specific application. > > > > This AVP SHOULD be placed as close to the Diameter header as > > possible. > > > > AVP Format > > > > ::= < AVP Header: 260 > > > 1* [ Vendor-Id ] > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > > > ===== > > > > > > 11.2.1 Command Codes > > > > The Command Code namespace is used to identify Diameter > commands. The > > values 0-255 are reserved for RADIUS backward > compatibility, and are > > defined as "RADIUS Packet Type Codes" in [RADTYPE]. The > remaining > > values are available via Standards Action [IANA]. > > > > Vendor-Specific Command Codes, where the Vendor-Id field in the > > Diameter header is set to a non-zero value, are for Private Use. > > From owner-aaa-wg@merit.edu Tue Jun 11 03:29: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 DAA15156 for ; Tue, 11 Jun 2002 03:29:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63C8791270; Tue, 11 Jun 2002 03:29:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 294A191273; Tue, 11 Jun 2002 03:29: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 E6CCA91270 for ; Tue, 11 Jun 2002 03:29:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7F6D5DDC5; Tue, 11 Jun 2002 03:29:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by segue.merit.edu (Postfix) with ESMTP id 1CFEB5DDAB for ; Tue, 11 Jun 2002 03:29:10 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA11449 for ; Tue, 11 Jun 2002 09:29:03 +0200 (MET DST) Received: from mchh168e.mch4.siemens.de ([139.21.130.175]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA11426 for ; Tue, 11 Jun 2002 09:29:17 +0200 (MET DST) Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 09:29:18 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E6DBED89@mchh161e> From: Daser Martin ICM N PG U ID A 3 To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes Date: Tue, 11 Jun 2002 09:29:07 +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, we have been following this discussion for a while. We think that the removal of vendor specific support from the base draft would certainly be very disruptive for the standards process. Eliminating parts parts of the draft and setting up a new one with the eliminated contents will take a lot of time and some more iterations in the standards process. What would be the benefit of removing vendor support from the base draft? --Martin > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Dienstag, 11. Juni 2002 09:06 > To: mccap@lucent.com; john.loughney@nokia.com > Cc: aboba@internaut.com; randy@psg.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter > command-codes > > > Hi, > > I fully support the Pete's view. > > In 3GPP the vendor-specific-application-Id AVP is widely > used. > In my understanding 3GPP has already been assigned the > vendor-id 10415. > Removing vendor-specific support from the Diameter base > it would actually be very disruptive. > > BR > Marco > > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@lucent.com] > > Sent: 10. June 2002 21:42 > > To: Loughney John (NRC/Helsinki) > > Cc: aboba@internaut.com; randy@psg.com; aaa-wg@merit.edu > > Subject: [AAA-WG]: Issue: Removal of vendor-specific Diameter > > command-codes > > > > > > > > Hi, > > > > As I understand it 3GPP is currently planning to define several > > 3GPP-specific Diameter applications. These include their Cx > > interface, for SIP authentication/authorization, the Sh > interface, for > > SIP application authentication/authorization, and the Charging > > application for IMS. I believe they plan to make extensive use of > > 3GPP-specific Vendor/Organization codes in these > applications, and to > > proceed on these applications without standards action in the IETF. > > Removing vendor-specific support from the Diameter base > protocol would > > be quite disruptive to these plans. > > > > -Pete > > > > john.loughney@nokia.com writes: > > > Hi all, > > > > > > If I have understood Randy Bush correctly, the IESG strongly > > > objects to the inclusion of support for vendor-specific > > command-codes > > > in the Diameter Base Protocol. > > > > > > The modifications needed to remove these are as follows: > > > > > > 1) removal of Vendor-ID from the Diameter Header. > > > 2) removal vendor-specific command-codes from 5.3.6 > > > 3) vendor-specific Diameter command-codes from 6.11 > > > 4) Discussion of vendor-specific Diameter command-codes in > > section 11.2.1 > > > > > > Below is the current text from Diameter 11 that discusses > > vendor-specific command-codes. > > > > > > Again, the proposal is that all mention of vendor-specific > > command-codes > > > would be removed. > > > > > > Please comment on the list. > > > > > > thanks, > > > John > > > > > > ============ > > > > > > 3 Diameter Header > > > > > > [text clipped] > > > > > > Vendor-ID > > > 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" > > > [ASSIGNNO] 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 vendor's vendor-specific > > command, nor with > > > future IETF applications. All vendor-specific > > Diameter commands > > > require Informational RFCs documenting the command > unless for > > > Private Use as described in Section 11.1.1. > > > > > > -> (11.1.1 needs to be changed to 11.2.1) > > > > > > ===== > > > > > > 5.3.6 Supported-Vendor-Id AVP > > > > > > The Supported-Vendor-Id AVP (AVP Code 265) is of type > > Unsigned32 and > > > contains the IANA "SMI Network Management Private > > Enterprise Codes" > > > [ASSIGNNO] value assigned to a vendor other than the > > device vendor. > > > This is used in the CER and CEA messages in order to > > inform the peer > > > that the sender supports a subset of the > > vendor-specific commands > > > and/or AVPs defined by the vendor identified in this AVP. > > > > > > ===== > > > > > > 6.11 Vendor-Specific-Application-Id AVP > > > > > > The Vendor-Specific-Application-Id AVP (AVP Code 260) > is of type > > > Grouped and is used to advertise support of a vendor-specific > > > Diameter Application. Exactly one of the > Auth-Application-Id and > > > Acct-Application-Id AVPs MAY be present. > > > > > > This AVP MUST also be present in all vendor-specific > > commands defined > > > in the vendor-specific application. > > > > > > This AVP SHOULD be placed as close to the Diameter header as > > > possible. > > > > > > AVP Format > > > > > > ::= < AVP Header: 260 > > > > 1* [ Vendor-Id ] > > > 0*1{ > Auth-Application-Id } > > > 0*1{ > Acct-Application-Id } > > > > > > ===== > > > > > > > > > 11.2.1 Command Codes > > > > > > The Command Code namespace is used to identify Diameter > > commands. The > > > values 0-255 are reserved for RADIUS backward > > compatibility, and are > > > defined as "RADIUS Packet Type Codes" in [RADTYPE]. The > > remaining > > > values are available via Standards Action [IANA]. > > > > > > Vendor-Specific Command Codes, where the Vendor-Id > field in the > > > Diameter header is set to a non-zero value, are for > Private Use. > > > > > From owner-aaa-wg@merit.edu Tue Jun 11 03:39: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 DAA15449 for ; Tue, 11 Jun 2002 03:39:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D80A191273; Tue, 11 Jun 2002 03:39:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7B9991274; Tue, 11 Jun 2002 03:39: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 AFFDD91273 for ; Tue, 11 Jun 2002 03:39:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AECDF5DDD0; Tue, 11 Jun 2002 03:39:22 -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 448285DDCB for ; Tue, 11 Jun 2002 03:39:22 -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 g5B7dJmG029777; Tue, 11 Jun 2002 09:39:19 +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 M3KJLPFA; Tue, 11 Jun 2002 09:39:19 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 09:39:19 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED2378@eestqnt104> From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'marco.stura@nokia.com'" , mccap@lucent.com, john.loughney@nokia.com Cc: aboba@internaut.com, randy@psg.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes Date: Tue, 11 Jun 2002 09:39:11 +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, I fully support the opinions expressed in favour of keeping the support of vendor specific applications. Best regards, Miguel -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: martes, 11 de junio de 2002 9:06 To: mccap@lucent.com; john.loughney@nokia.com Cc: aboba@internaut.com; randy@psg.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes Hi, I fully support the Pete's view. In 3GPP the vendor-specific-application-Id AVP is widely used. In my understanding 3GPP has already been assigned the vendor-id 10415. Removing vendor-specific support from the Diameter base it would actually be very disruptive. BR Marco > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 10. June 2002 21:42 > To: Loughney John (NRC/Helsinki) > Cc: aboba@internaut.com; randy@psg.com; aaa-wg@merit.edu > Subject: [AAA-WG]: Issue: Removal of vendor-specific Diameter > command-codes > > > > Hi, > > As I understand it 3GPP is currently planning to define several > 3GPP-specific Diameter applications. These include their Cx > interface, for SIP authentication/authorization, the Sh interface, for > SIP application authentication/authorization, and the Charging > application for IMS. I believe they plan to make extensive use of > 3GPP-specific Vendor/Organization codes in these applications, and to > proceed on these applications without standards action in the IETF. > Removing vendor-specific support from the Diameter base protocol would > be quite disruptive to these plans. > > -Pete > > john.loughney@nokia.com writes: > > Hi all, > > > > If I have understood Randy Bush correctly, the IESG strongly > > objects to the inclusion of support for vendor-specific > command-codes > > in the Diameter Base Protocol. > > > > The modifications needed to remove these are as follows: > > > > 1) removal of Vendor-ID from the Diameter Header. > > 2) removal vendor-specific command-codes from 5.3.6 > > 3) vendor-specific Diameter command-codes from 6.11 > > 4) Discussion of vendor-specific Diameter command-codes in > section 11.2.1 > > > > Below is the current text from Diameter 11 that discusses > vendor-specific command-codes. > > > > Again, the proposal is that all mention of vendor-specific > command-codes > > would be removed. > > > > Please comment on the list. > > > > thanks, > > John > > > > ============ > > > > 3 Diameter Header > > > > [text clipped] > > > > Vendor-ID > > 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" > > [ASSIGNNO] 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 vendor's vendor-specific > command, nor with > > future IETF applications. All vendor-specific > Diameter commands > > require Informational RFCs documenting the command unless for > > Private Use as described in Section 11.1.1. > > > > -> (11.1.1 needs to be changed to 11.2.1) > > > > ===== > > > > 5.3.6 Supported-Vendor-Id AVP > > > > The Supported-Vendor-Id AVP (AVP Code 265) is of type > Unsigned32 and > > contains the IANA "SMI Network Management Private > Enterprise Codes" > > [ASSIGNNO] value assigned to a vendor other than the > device vendor. > > This is used in the CER and CEA messages in order to > inform the peer > > that the sender supports a subset of the > vendor-specific commands > > and/or AVPs defined by the vendor identified in this AVP. > > > > ===== > > > > 6.11 Vendor-Specific-Application-Id AVP > > > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > > Grouped and is used to advertise support of a vendor-specific > > Diameter Application. Exactly one of the Auth-Application-Id and > > Acct-Application-Id AVPs MAY be present. > > > > This AVP MUST also be present in all vendor-specific > commands defined > > in the vendor-specific application. > > > > This AVP SHOULD be placed as close to the Diameter header as > > possible. > > > > AVP Format > > > > ::= < AVP Header: 260 > > > 1* [ Vendor-Id ] > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > > > ===== > > > > > > 11.2.1 Command Codes > > > > The Command Code namespace is used to identify Diameter > commands. The > > values 0-255 are reserved for RADIUS backward > compatibility, and are > > defined as "RADIUS Packet Type Codes" in [RADTYPE]. The > remaining > > values are available via Standards Action [IANA]. > > > > Vendor-Specific Command Codes, where the Vendor-Id field in the > > Diameter header is set to a non-zero value, are for Private Use. > > From owner-aaa-wg@merit.edu Tue Jun 11 04:49: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 EAA16217 for ; Tue, 11 Jun 2002 04:49:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 082B491274; Tue, 11 Jun 2002 04:49:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7FA491275; Tue, 11 Jun 2002 04:49:12 -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 C1FEA91274 for ; Tue, 11 Jun 2002 04:49:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C55C45DDD6; Tue, 11 Jun 2002 04:49:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id 104915DD99 for ; Tue, 11 Jun 2002 04:49:07 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep04-svc.swip.net with ESMTP id <20020611084914.DXOF6282.fep04-svc.swip.net@ipunplugged.com>; Tue, 11 Jun 2002 10:49:14 +0200 Message-ID: <3D05BA08.5080400@ipunplugged.com> Date: Tue, 11 Jun 2002 10:51:20 +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]: Request for IETF last call on Diameter-11 and Trans port-07 drafts References: <4D79C746863DD51197690002A52CDA0001E8A5B4@zcard0kc.ca.nortel.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 Randy and others, I hereby join the officially confused party. Specific items of confusion below. Randy Bush wrote: >it's two things > >in general, extensions need ietf process. > Try as I may to grasp it the meaning of that statement eludes me.Your objection is against vendor-specific extensions. I would have thought that they by definition were outside the scope of ietf. The whole purpose of making a vendor-specific extension is to avoid ietf process. If it goes through ietf process, in what way would it be vendor-specific? >and, non-standard extensions can not be mandatory. e.g. when dynamic >negotiation over an extension fails, the fault must clearly be with >the side demanding the extension, not the side not implementing it. > This is self-evident. Where and in what way do the current drafts fail to meet this criterion? Wouldn't it be better to quickly fix these problems rather than to remove a feature that we know beyond a shadow of a doubt will be requested and implemented by ugly hacks if we don't provide a controlled means for it? j From owner-aaa-wg@merit.edu Tue Jun 11 04:50: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 EAA16273 for ; Tue, 11 Jun 2002 04:50:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16E3B91275; Tue, 11 Jun 2002 04:50:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D69F191276; Tue, 11 Jun 2002 04:50: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 CC9EF91275 for ; Tue, 11 Jun 2002 04:50:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA8295DDD6; Tue, 11 Jun 2002 04:50:38 -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 26E475DD99 for ; Tue, 11 Jun 2002 04:50:38 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020611085045.EEVS15064.fep02-svc.swip.net@ipunplugged.com>; Tue, 11 Jun 2002 10:50:45 +0200 Message-ID: <3D05BA63.8000702@ipunplugged.com> Date: Tue, 11 Jun 2002 10:52:51 +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: "Miguel-Angel Pallares-Lopez (ECE)" Cc: "'marco.stura@nokia.com'" , mccap@lucent.com, john.loughney@nokia.com, aboba@internaut.com, randy@psg.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes References: <577066326047D41180AC00508B955DDA05ED2378@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 As do I. j Miguel-Angel Pallares-Lopez (ECE) wrote: >Hi, > >I fully support the opinions expressed in favour of keeping the support of vendor specific applications. > >Best regards, >Miguel > > From owner-aaa-wg@merit.edu Tue Jun 11 04:55:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16382 for ; Tue, 11 Jun 2002 04:55:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82BC591276; Tue, 11 Jun 2002 04:55:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4837391277; Tue, 11 Jun 2002 04:55: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 2C03891276 for ; Tue, 11 Jun 2002 04:55:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CDC85DDD9; Tue, 11 Jun 2002 04:55:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 525F95DD99 for ; Tue, 11 Jun 2002 04:55:39 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5B8slG09473; Tue, 11 Jun 2002 10:54:47 +0200 (MEST) 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 g5B8sbQ15674; Tue, 11 Jun 2002 09:54:41 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 09:54:40 +0100 Message-ID: From: "Daniel Warren" To: aaa-wg@merit.edu Cc: aboba@internaut.com, randy@psg.com, "'marco.stura@nokia.com'" , mccap@lucent.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes Date: Tue, 11 Jun 2002 09:54:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21125.9D588422" 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_01C21125.9D588422 Content-Type: text/plain; charset="iso-8859-1" All I have to say that I am concerned by the proposal that John Loughney has communicated here. It was my understanding that vendor specific extension was exactly that - a facility whereby a vendor can include additional commands to facilitate the extension of Diameter Base Protocol or Diameter Applications to enhance their specific implementation. Vendors are given a vendor id and using that, they may identify that something is a specific extension and defined command codes under that vendor id as they see fit. The fact that the vendor id is present should be enough to separate the standardised commands in IETF applications and those which are, for want of a better word, 'proprietary'. Having looked at Randy's comments, it strikes me that he is not concerned about the proposals as a whole but more concerned about 'mandatory' extensions. My feeling on this is that if an extension is vendor specific, it is implicitly optional. If it were not optional then all vendors' implementations would have to support it, and then it is not vendor specific anymore. I really do not see the need to change what is in the text right now. Regards Dan Warren -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 11 June 2002 08:06 To: mccap@lucent.com; john.loughney@nokia.com Cc: aboba@internaut.com; randy@psg.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes Hi, I fully support the Pete's view. In 3GPP the vendor-specific-application-Id AVP is widely used. In my understanding 3GPP has already been assigned the vendor-id 10415. Removing vendor-specific support from the Diameter base it would actually be very disruptive. BR Marco > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 10. June 2002 21:42 > To: Loughney John (NRC/Helsinki) > Cc: aboba@internaut.com; randy@psg.com; aaa-wg@merit.edu > Subject: [AAA-WG]: Issue: Removal of vendor-specific Diameter > command-codes > > > > Hi, > > As I understand it 3GPP is currently planning to define several > 3GPP-specific Diameter applications. These include their Cx > interface, for SIP authentication/authorization, the Sh interface, for > SIP application authentication/authorization, and the Charging > application for IMS. I believe they plan to make extensive use of > 3GPP-specific Vendor/Organization codes in these applications, and to > proceed on these applications without standards action in the IETF. > Removing vendor-specific support from the Diameter base protocol would > be quite disruptive to these plans. > > -Pete > > john.loughney@nokia.com writes: > > Hi all, > > > > If I have understood Randy Bush correctly, the IESG strongly > > objects to the inclusion of support for vendor-specific > command-codes > > in the Diameter Base Protocol. > > > > The modifications needed to remove these are as follows: > > > > 1) removal of Vendor-ID from the Diameter Header. > > 2) removal vendor-specific command-codes from 5.3.6 > > 3) vendor-specific Diameter command-codes from 6.11 > > 4) Discussion of vendor-specific Diameter command-codes in > section 11.2.1 > > > > Below is the current text from Diameter 11 that discusses > vendor-specific command-codes. > > > > Again, the proposal is that all mention of vendor-specific > command-codes > > would be removed. > > > > Please comment on the list. > > > > thanks, > > John > > > > ============ > > > > 3 Diameter Header > > > > [text clipped] > > > > Vendor-ID > > 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" > > [ASSIGNNO] 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 vendor's vendor-specific > command, nor with > > future IETF applications. All vendor-specific > Diameter commands > > require Informational RFCs documenting the command unless for > > Private Use as described in Section 11.1.1. > > > > -> (11.1.1 needs to be changed to 11.2.1) > > > > ===== > > > > 5.3.6 Supported-Vendor-Id AVP > > > > The Supported-Vendor-Id AVP (AVP Code 265) is of type > Unsigned32 and > > contains the IANA "SMI Network Management Private > Enterprise Codes" > > [ASSIGNNO] value assigned to a vendor other than the > device vendor. > > This is used in the CER and CEA messages in order to > inform the peer > > that the sender supports a subset of the > vendor-specific commands > > and/or AVPs defined by the vendor identified in this AVP. > > > > ===== > > > > 6.11 Vendor-Specific-Application-Id AVP > > > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > > Grouped and is used to advertise support of a vendor-specific > > Diameter Application. Exactly one of the Auth-Application-Id and > > Acct-Application-Id AVPs MAY be present. > > > > This AVP MUST also be present in all vendor-specific > commands defined > > in the vendor-specific application. > > > > This AVP SHOULD be placed as close to the Diameter header as > > possible. > > > > AVP Format > > > > ::= < AVP Header: 260 > > > 1* [ Vendor-Id ] > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > > > ===== > > > > > > 11.2.1 Command Codes > > > > The Command Code namespace is used to identify Diameter > commands. The > > values 0-255 are reserved for RADIUS backward > compatibility, and are > > defined as "RADIUS Packet Type Codes" in [RADTYPE]. The > remaining > > values are available via Standards Action [IANA]. > > > > Vendor-Specific Command Codes, where the Vendor-Id field in the > > Diameter header is set to a non-zero value, are for Private Use. > > ------_=_NextPart_001_01C21125.9D588422 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter = command-codes

All

I have to say that I am concerned by the proposal = that John Loughney has communicated here.  It was my understanding = that vendor specific extension was exactly that - a facility whereby a = vendor can include additional commands to facilitate the extension of = Diameter Base Protocol or Diameter Applications to enhance their = specific implementation.  Vendors are given a vendor id and using = that, they may identify that something is a specific extension and = defined command codes under that vendor id as they see fit.  The = fact that the vendor id is present should be enough to separate the = standardised commands in IETF applications and those which are, for = want of a better word, 'proprietary'.

Having looked at Randy's comments, it strikes me that = he is not concerned about the proposals as a whole but more concerned = about 'mandatory' extensions.  My feeling on this is that if an = extension is vendor specific, it is implicitly optional.  If it = were not optional then all vendors' implementations would have to = support it, and then it is not vendor specific anymore.

I really do not see the need to change what is in the = text right now.

Regards

Dan Warren

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]<= /FONT>
Sent: 11 June 2002 08:06
To: mccap@lucent.com; john.loughney@nokia.com
Cc: aboba@internaut.com; randy@psg.com; = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Issue: Removal of = vendor-specific Diameter
command-codes


Hi,

I fully support the Pete's view.

In 3GPP the vendor-specific-application-Id AVP is = widely
used.
In my understanding 3GPP has already been assigned = the
vendor-id 10415.
Removing vendor-specific support from the Diameter = base
it would actually be very disruptive.

BR
Marco

> -----Original Message-----
> From: ext Pete McCann [mailto:mccap@lucent.com]
> Sent: 10. June 2002 21:42
> To: Loughney John (NRC/Helsinki)
> Cc: aboba@internaut.com; randy@psg.com; = aaa-wg@merit.edu
> Subject: [AAA-WG]: Issue: Removal of = vendor-specific Diameter
> command-codes
>
>
>
> Hi,
>
> As I understand it 3GPP is currently planning = to define several
> 3GPP-specific Diameter applications.  = These include their Cx
> interface, for SIP = authentication/authorization, the Sh interface, for
> SIP application authentication/authorization, = and the Charging
> application for IMS.  I believe they plan = to make extensive use of
> 3GPP-specific Vendor/Organization codes in = these applications, and to
> proceed on these applications without standards = action in the IETF.
> Removing vendor-specific support from the = Diameter base protocol would
> be quite disruptive to these plans.
>
> -Pete
>
> john.loughney@nokia.com writes:
>  > Hi all,
>  >
>  > If I have understood Randy Bush = correctly, the IESG strongly
>  > objects to the inclusion of support = for vendor-specific
> command-codes
>  > in the Diameter Base = Protocol.
>  >
>  > The modifications needed to remove = these are as follows:
>  >
>  > 1) removal of Vendor-ID from the = Diameter Header.
>  > 2) removal vendor-specific = command-codes from 5.3.6
>  > 3) vendor-specific Diameter = command-codes from 6.11
>  > 4) Discussion of vendor-specific = Diameter command-codes in
> section 11.2.1
>  >
>  > Below is the current text from = Diameter 11 that discusses
> vendor-specific command-codes.
>  >
>  > Again, the proposal is that all = mention of vendor-specific
> command-codes
>  > would be removed.
>  >
>  > Please comment on the list.
>  >
>  > thanks,
>  > John
>  >
>  > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  >
>  > 3  Diameter Header
>  >
>  > [text clipped]
>  >
>  >    Vendor-ID
>  >       = 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"
>  >       = [ASSIGNNO] 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 vendor's vendor-specific
> command, nor with
>  >       = future IETF applications. All vendor-specific
> Diameter commands
>  >       = require Informational RFCs documenting the command unless for
>  >       = Private Use as described in Section 11.1.1.
>  >
>  > -> (11.1.1 needs to be changed to = 11.2.1)
>  >
>  > =3D=3D=3D=3D=3D
>  >
>  > 5.3.6  Supported-Vendor-Id = AVP
>  >
>  >    The = Supported-Vendor-Id AVP (AVP Code 265) is of type
> Unsigned32 and
>  >    contains the IANA = "SMI Network Management Private
> Enterprise Codes"
>  >    [ASSIGNNO] value = assigned to a vendor other than the
> device vendor.
>  >    This is used in = the CER and CEA messages in order to
> inform the peer
>  >    that the sender = supports a subset of the
> vendor-specific commands
>  >    and/or AVPs = defined by the vendor identified in this AVP.
>  >
>  > =3D=3D=3D=3D=3D
>  >
>  > 6.11  = Vendor-Specific-Application-Id AVP
>  >
>  >    The = Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
>  >    Grouped and is = used to advertise support of a vendor-specific
>  >    Diameter = Application. Exactly one of the Auth-Application-Id and
>  >    = Acct-Application-Id AVPs MAY be present.
>  >
>  >    This AVP MUST also = be present in all vendor-specific
> commands defined
>  >    in the = vendor-specific application.
>  >
>  >    This AVP SHOULD be = placed as close to the Diameter header as
>  >    possible.
>  >
>  >    AVP Format
>  >
>  >       = <Vendor-Specific-Application-Id> ::=3D < AVP Header: 260 = >
>  = >           &n= bsp;           &n= bsp;           &n= bsp;     1* [ Vendor-Id ]
>  = >           &n= bsp;           &n= bsp;           &n= bsp;     0*1{ Auth-Application-Id }
>  = >           &n= bsp;           &n= bsp;           &n= bsp;     0*1{ Acct-Application-Id }
>  >
>  > =3D=3D=3D=3D=3D
>  >
>  >
>  > 11.2.1  Command Codes
>  >
>  >    The Command Code = namespace is used to identify Diameter
> commands. The
>  >    values 0-255 are = reserved for RADIUS backward
> compatibility, and are
>  >    defined as = "RADIUS Packet Type Codes" in [RADTYPE]. The
> remaining
>  >    values are = available via Standards Action [IANA].
>  >
>  >    Vendor-Specific = Command Codes, where the Vendor-Id field in the
>  >    Diameter header is = set to a non-zero value, are for Private Use.
>
>

------_=_NextPart_001_01C21125.9D588422-- From owner-aaa-wg@merit.edu Tue Jun 11 05:11: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 FAA16504 for ; Tue, 11 Jun 2002 05:11:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD8A291277; Tue, 11 Jun 2002 05:11:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A71BA91278; Tue, 11 Jun 2002 05:11: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 82BFC91277 for ; Tue, 11 Jun 2002 05:11:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8AF505DDCB; Tue, 11 Jun 2002 05:11:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id B52F15DD99 for ; Tue, 11 Jun 2002 05:11:35 -0400 (EDT) Received: from cisco.com ([10.77.201.96]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA14494; Tue, 11 Jun 2002 14:40:20 +0530 (IST) Message-ID: <3D05BEC3.BEECC13C@cisco.com> Date: Tue, 11 Jun 2002 14:41:31 +0530 From: Sakthidaran V X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Warren Cc: aaa-wg@merit.edu, aboba@internaut.com, randy@psg.com, "'marco.stura@nokia.com'" , mccap@lucent.com, john.loughney@nokia.com Subject: Re: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes References: Content-Type: multipart/alternative; boundary="------------A4759D4ED283A228E083603D" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------A4759D4ED283A228E083603D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , > My feeling on this is that if an extension is vendor specific, it is implicitly optional. If it were not > optional then all vendors' implementations would have to support it, and then it is not vendor specific anymore. > I too agree with Daniel . Thank you for your time . Regds Shakthi svadakey@cisco.com --------------A4759D4ED283A228E083603D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ,
 
  
 My feeling on this is that if an extension is vendor specific, it is implicitly optional.  If it were not
optional then all vendors' implementations would have to support it, and then it is not vendor specific anymore.


I too agree with Daniel .
 
 
 

Thank you for your time .
 

Regds
Shakthi
svadakey@cisco.com
 
 
  --------------A4759D4ED283A228E083603D-- From owner-aaa-wg@merit.edu Tue Jun 11 05:12:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16520 for ; Tue, 11 Jun 2002 05:12:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D75291278; Tue, 11 Jun 2002 05:12:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1724791279; Tue, 11 Jun 2002 05:12: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 0B0ED91278 for ; Tue, 11 Jun 2002 05:12:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C7E15DDCB; Tue, 11 Jun 2002 05:12: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 657205DD99 for ; Tue, 11 Jun 2002 05:12:42 -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 g5B9DHi23089 for ; Tue, 11 Jun 2002 12:13:17 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 11 Jun 2002 12:12:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 12:12:50 +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]: Edits to Diameter 11 to resolve vendor-specific command code issue Date: Tue, 11 Jun 2002 12:12:50 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E4C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes Thread-Index: AcIRGyEyouhQNOtORZKjBXj1ovrjJQAA59RQ From: To: X-OriginalArrivalTime: 11 Jun 2002 09:12:50.0482 (UTC) FILETIME=[290C2120:01C21128] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA16520 Hi all, Here is my suggested text for Diameter to fix this issue. John 1.2 Approach to Extensibility The Diameter protocol is designed to be extensible. However, it is strongly encouraged to reuse existing mechanisms before attempting any Diameter extensions. The extensibility includes: - Defining new AVP values. - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures The extension MUST be documented through an IETF process. The documentation MUST describe interaction with Diameter peers that do not implement the extension. ****** 3 Diameter Header [clip] Vendor-ID 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" [ASSIGNNO] 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 vendor's vendor-specific command, nor with future IETF applications. All vendor-specific Diameter commands require Informational RFCs documenting the command and specifying interoperation with Diameter peers not implementing the command. From owner-aaa-wg@merit.edu Tue Jun 11 05:41: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 FAA16803 for ; Tue, 11 Jun 2002 05:41:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED70191279; Tue, 11 Jun 2002 05:41:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2F0C9127B; Tue, 11 Jun 2002 05:41: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 7E58491279 for ; Tue, 11 Jun 2002 05:41:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F8555DDCC; Tue, 11 Jun 2002 05:41:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 2BDA55DDDA for ; Tue, 11 Jun 2002 05:41:23 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5B9fUG06316; Tue, 11 Jun 2002 11:41:30 +0200 (MEST) 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 g5B9fSQ01987; Tue, 11 Jun 2002 10:41:28 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 10:41:31 +0100 Message-ID: From: "Daniel Warren" To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue Date: Tue, 11 Jun 2002 10:41:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2112C.29A6E292" 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_01C2112C.29A6E292 Content-Type: text/plain; charset="iso-8859-1" John I have little problem with this text except for the part that says;- 'All vendor-specific Diameter commands require Informational RFCs documenting the command and specifying interoperation with Diameter peers not implementing the command.' There are two points about this that I would like to make. First, if a vendor is extending Diameter in some way that it intends to only use between it's own nodes, why should it reveal that extension to the public domain. In cases where interoperability with another vendor's equipment is required, then the vendors would exchange information on relevant extensions. I see no good reason for any vendor to submit this information to IETF as it removes the insentive for private innovation and negates the possibility of vendor differentiation. One of the key points of Diameter is that it is easily extensible. Putting this kind of bureaucracy in place removes that ease. Second, if you accept the points that Johan and I made with regard to optionality, the behaviour of a peer not implementing the command can be defined here and now as 'ignore it'. My feeling is that if you define the behaviour of the receiving peer when it receives a command with a vendor-id it does not recognise (or even one that it does know but with a command code that it doesn't believe to be associated with that vendor-id) as 'ignore the command', then doesn't the requirement for the informational RFC's go away? Who cares what the commands are if all I need to know is that if I don't recognise it, I don't do anything with it... Regards Dan -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: 11 June 2002 10:13 To: aaa-wg@merit.edu Subject: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Hi all, Here is my suggested text for Diameter to fix this issue. John 1.2 Approach to Extensibility The Diameter protocol is designed to be extensible. However, it is strongly encouraged to reuse existing mechanisms before attempting any Diameter extensions. The extensibility includes: - Defining new AVP values. - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures The extension MUST be documented through an IETF process. The documentation MUST describe interaction with Diameter peers that do not implement the extension. ****** 3 Diameter Header [clip] Vendor-ID 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" [ASSIGNNO] 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 vendor's vendor-specific command, nor with future IETF applications. All vendor-specific Diameter commands require Informational RFCs documenting the command and specifying interoperation with Diameter peers not implementing the command. ------_=_NextPart_001_01C2112C.29A6E292 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific = command code issue

John

I have little problem with this text except for the = part that says;-

'All vendor-specific Diameter commands require = Informational RFCs documenting the command and specifying = interoperation with Diameter peers not implementing the = command.'

There are two points about this that I would like to = make.  First, if a vendor is  extending Diameter in some way = that it intends to only use between it's own nodes, why should it = reveal that extension to the public domain.  In cases where = interoperability with another vendor's equipment is required, then the = vendors would exchange information on relevant extensions.  I see = no good reason for any vendor to submit this information to IETF as it = removes the insentive for private innovation and negates the = possibility of vendor differentiation.  One of the key points of = Diameter is that it is easily extensible.  Putting this kind of = bureaucracy in place removes that ease.

Second, if you accept the points that Johan and I = made with regard to optionality, the behaviour of a peer not = implementing the command can be defined here and now as 'ignore = it'. 

My feeling is that if you define the behaviour of the = receiving peer when it receives a command with a vendor-id it does not = recognise (or even one that it does know but with a command code that = it doesn't believe to be associated with that vendor-id) as 'ignore the = command', then doesn't the requirement for the informational RFC's go = away?  Who cares what the commands are if all I need to know is = that if I don't recognise it, I don't do anything with it...

Regards

Dan

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: 11 June 2002 10:13
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Edits to Diameter 11 to resolve = vendor-specific
command code issue


Hi all,

Here is my suggested text for Diameter to fix this = issue.

John


1.2  Approach to Extensibility

   The Diameter protocol is designed to be = extensible. However, it is
   strongly encouraged to reuse existing = mechanisms before attempting
   any Diameter extensions.  The = extensibility includes:

      - Defining new AVP = values.
      - Creating new = AVPs
      - Creating new = authentication/authorization applications
      - Creating new = accounting applications
      - Application = authentication procedures

   The extension MUST be documented through = an IETF process.  The
   documentation MUST describe interaction = with Diameter peers
   that do not implement the = extension.

******

3  Diameter Header

[clip]

   Vendor-ID
      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"
      [ASSIGNNO] 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 vendor's vendor-specific command, nor with
      future IETF = applications. All vendor-specific Diameter commands
      require Informational = RFCs documenting the command and specifying
        interoperation with Diameter peers not implementing the = command.       

------_=_NextPart_001_01C2112C.29A6E292-- From owner-aaa-wg@merit.edu Tue Jun 11 05:55: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 FAA16930 for ; Tue, 11 Jun 2002 05:55:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 393439127B; Tue, 11 Jun 2002 05:55:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AEA59127C; Tue, 11 Jun 2002 05:55:26 -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 DCB489127B for ; Tue, 11 Jun 2002 05:55:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED14E5DDDA; Tue, 11 Jun 2002 05:55:21 -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 1B4675DDCC for ; Tue, 11 Jun 2002 05:55:21 -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 g5B9tti00952 for ; Tue, 11 Jun 2002 12:55:55 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 12:55:29 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 12:55:28 +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]: Edits to Diameter 11 to resolve vendor-specific command code issue Date: Tue, 11 Jun 2002 12:55:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653D8@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Thread-Index: AcIRLD08vd4CZd44QKyWtb0a2Y6ZBAAAPmVA From: To: , X-OriginalArrivalTime: 11 Jun 2002 09:55:28.0756 (UTC) FILETIME=[1DE5C340:01C2112E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA16930 Hi Dan, I think Randy, as Area Director, may need to speak to the concerns that documenting extensions as an Information RFC may be too difficult. The IESG has raised the issue that all Diameter extensions need a paper trail & informational RFCs are the way to provide a paper trail in the IETF. > I have little problem with this text except for the part that says;- > > 'All vendor-specific Diameter commands require Informational RFCs documenting > the command and specifying interoperation with Diameter peers not implementing > the command.' > > There are two points about this that I would like to make. First, if a vendor > is extending Diameter in some way that it intends to only use between it's own > nodes, why should it reveal that extension to the public domain. In cases where > interoperability with another vendor's equipment is required, then the vendors > would exchange information on relevant extensions. I see no good reason for any > vendor to submit this information to IETF as it removes the insentive for private > innovation and negates the possibility of vendor differentiation. One of the key > points of Diameter is that it is easily extensible. Putting this kind of bureaucracy > in place removes that ease. My feeling is that if a vendor implements Diameter with non-standard commands, then they are doing just that, having a non-standard Diameter implementation. If they wish to have extensions to Diameter, then those extensions should be standardized, some sort. > Second, if you accept the points that Johan and I made with regard to optionality, > the behaviour of a peer not implementing the command can be defined here and now as > 'ignore it'. Randy's comment has been that the current text in Diameter indicates that it is not optional. Obviously, then we need additional text in the base spec. > My feeling is that if you define the behaviour of the receiving peer when it receives > a command with a vendor-id it does not recognise (or even one that it does know but > with a command code that it doesn't believe to be associated with that vendor-id) > as 'ignore the command', then doesn't the requirement for the informational RFC's go away? I think that text should be added to the spec, but I don't that the requirement goes away. The problem is that there is no way to guarentee that an extension is used only in a closed network (not visible to the interenet). If it is a useful extension, then why not document it. If it is not useful, why do it in the first place? John From owner-aaa-wg@merit.edu Tue Jun 11 05:59: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 FAA17013 for ; Tue, 11 Jun 2002 05:59:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B366D9127C; Tue, 11 Jun 2002 06:00:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5163D9127D; Tue, 11 Jun 2002 06:00:02 -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 3EAF79127C for ; Tue, 11 Jun 2002 06:00:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 42D9B5DDDA; Tue, 11 Jun 2002 05:59:56 -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 80A0C5DDCC for ; Tue, 11 Jun 2002 05:59:55 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep03-svc.swip.net with ESMTP id <20020611100003.ELZB13176.fep03-svc.swip.net@ipunplugged.com>; Tue, 11 Jun 2002 12:00:03 +0200 Message-ID: <3D05CAA0.9010702@ipunplugged.com> Date: Tue, 11 Jun 2002 12:02:08 +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: john.loughney@nokia.com Cc: dlwarren@nortelnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653D8@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 john.loughney@nokia.com wrote: >>My feeling is that if you define the behaviour of the receiving peer when it receives >>a command with a vendor-id it does not recognise (or even one that it does know but >>with a command code that it doesn't believe to be associated with that vendor-id) >>as 'ignore the command', then doesn't the requirement for the informational RFC's go away? >> >> > >I think that text should be added to the spec, but I don't that the requirement goes away. >The problem is that there is no way to guarentee that an extension is used only in a >closed network (not visible to the interenet). If it is a useful extension, then why >not document it. If it is not useful, why do it in the first place? > If I were to define some messages to e.g. exchange state information between AAA servers the contents of that message almost certainly would depend on the implementation and would be useful to me but probably of little use to anyone else. j From owner-aaa-wg@merit.edu Tue Jun 11 06:00:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17039 for ; Tue, 11 Jun 2002 06:00:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D07049127D; Tue, 11 Jun 2002 06:00:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99A219127E; Tue, 11 Jun 2002 06:00:30 -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 4A1829127D for ; Tue, 11 Jun 2002 06:00:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4276D5DDA7; Tue, 11 Jun 2002 06:00:23 -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 BA34E5DD99 for ; Tue, 11 Jun 2002 06:00:22 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5BA0U6n003785 for ; Tue, 11 Jun 2002 12:00:30 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M3J3QHYA; Tue, 11 Jun 2002 12:00:30 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 12:00:30 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED237B@eestqnt104> X-Sybari-Trust: 40831c3f 2a03b045 623d418c 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue Date: Tue, 11 Jun 2002 12:00:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2112E.CE99F800" 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_01C2112E.CE99F800 Content-Type: text/plain; charset="iso-8859-1" Hi, I support Dan's statement. What is missing in the existing capabilities exchange procedure that doesn't allow a pre-negotiation of the vendor-specific applications that two peers support? If a peer supporting a vendor-specific application doesn't receive the indication from the corresponding peer of the support of the same application, according to existing text in the base, it mustn't send commands belonging to such application. BR/Miguel -----Original Message----- From: Daniel Warren [mailto:dlwarren@nortelnetworks.com] Sent: martes, 11 de junio de 2002 11:41 To: 'john.loughney@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue John I have little problem with this text except for the part that says;- 'All vendor-specific Diameter commands require Informational RFCs documenting the command and specifying interoperation with Diameter peers not implementing the command.' There are two points about this that I would like to make. First, if a vendor is extending Diameter in some way that it intends to only use between it's own nodes, why should it reveal that extension to the public domain. In cases where interoperability with another vendor's equipment is required, then the vendors would exchange information on relevant extensions. I see no good reason for any vendor to submit this information to IETF as it removes the insentive for private innovation and negates the possibility of vendor differentiation. One of the key points of Diameter is that it is easily extensible. Putting this kind of bureaucracy in place removes that ease. Second, if you accept the points that Johan and I made with regard to optionality, the behaviour of a peer not implementing the command can be defined here and now as 'ignore it'. My feeling is that if you define the behaviour of the receiving peer when it receives a command with a vendor-id it does not recognise (or even one that it does know but with a command code that it doesn't believe to be associated with that vendor-id) as 'ignore the command', then doesn't the requirement for the informational RFC's go away? Who cares what the commands are if all I need to know is that if I don't recognise it, I don't do anything with it... Regards Dan -----Original Message----- From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com ] Sent: 11 June 2002 10:13 To: aaa-wg@merit.edu Subject: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Hi all, Here is my suggested text for Diameter to fix this issue. John 1.2 Approach to Extensibility The Diameter protocol is designed to be extensible. However, it is strongly encouraged to reuse existing mechanisms before attempting any Diameter extensions. The extensibility includes: - Defining new AVP values. - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures The extension MUST be documented through an IETF process. The documentation MUST describe interaction with Diameter peers that do not implement the extension. ****** 3 Diameter Header [clip] Vendor-ID 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" [ASSIGNNO] 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 vendor's vendor-specific command, nor with future IETF applications. All vendor-specific Diameter commands require Informational RFCs documenting the command and specifying interoperation with Diameter peers not implementing the command. ------_=_NextPart_001_01C2112E.CE99F800 Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue
Hi,
 
I support Dan's statement.
 
What is missing in the existing capabilities exchange procedure that doesn't allow a pre-negotiation of the vendor-specific applications that two peers support? If a peer supporting a vendor-specific application doesn't receive the indication from the corresponding peer of the support of the same application, according to existing text in the base, it mustn't send commands belonging to such application.
 
BR/Miguel
-----Original Message-----
From: Daniel Warren [mailto:dlwarren@nortelnetworks.com]
Sent: martes, 11 de junio de 2002 11:41
To: 'john.loughney@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue

John

I have little problem with this text except for the part that says;-

'All vendor-specific Diameter commands require Informational RFCs documenting the command and specifying interoperation with Diameter peers not implementing the command.'

There are two points about this that I would like to make.  First, if a vendor is  extending Diameter in some way that it intends to only use between it's own nodes, why should it reveal that extension to the public domain.  In cases where interoperability with another vendor's equipment is required, then the vendors would exchange information on relevant extensions.  I see no good reason for any vendor to submit this information to IETF as it removes the insentive for private innovation and negates the possibility of vendor differentiation.  One of the key points of Diameter is that it is easily extensible.  Putting this kind of bureaucracy in place removes that ease.

Second, if you accept the points that Johan and I made with regard to optionality, the behaviour of a peer not implementing the command can be defined here and now as 'ignore it'. 

My feeling is that if you define the behaviour of the receiving peer when it receives a command with a vendor-id it does not recognise (or even one that it does know but with a command code that it doesn't believe to be associated with that vendor-id) as 'ignore the command', then doesn't the requirement for the informational RFC's go away?  Who cares what the commands are if all I need to know is that if I don't recognise it, I don't do anything with it...

Regards

Dan

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: 11 June 2002 10:13
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific
command code issue


Hi all,

Here is my suggested text for Diameter to fix this issue.

John


1.2  Approach to Extensibility

   The Diameter protocol is designed to be extensible. However, it is
   strongly encouraged to reuse existing mechanisms before attempting
   any Diameter extensions.  The extensibility includes:

      - Defining new AVP values.
      - Creating new AVPs
      - Creating new authentication/authorization applications
      - Creating new accounting applications
      - Application authentication procedures

   The extension MUST be documented through an IETF process.  The
   documentation MUST describe interaction with Diameter peers
   that do not implement the extension.

******

3  Diameter Header

[clip]

   Vendor-ID
      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"
      [ASSIGNNO] 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 vendor's vendor-specific command, nor with
      future IETF applications. All vendor-specific Diameter commands
      require Informational RFCs documenting the command and specifying
        interoperation with Diameter peers not implementing the command.       

------_=_NextPart_001_01C2112E.CE99F800-- From owner-aaa-wg@merit.edu Tue Jun 11 06:12: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 GAA17195 for ; Tue, 11 Jun 2002 06:12:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98D219127E; Tue, 11 Jun 2002 06:12:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6461F9127F; Tue, 11 Jun 2002 06:12:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74D959127E for ; Tue, 11 Jun 2002 06:12:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D2D95DDDA; Tue, 11 Jun 2002 06:12:27 -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 D78205DD99 for ; Tue, 11 Jun 2002 06:12:26 -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 g5BACZmG029070 for ; Tue, 11 Jun 2002 12:12:35 +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 M3KJNJ9H; Tue, 11 Jun 2002 12:12:35 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 12:12:34 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED237C@eestqnt104> From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'aaa-wg@merit.edu'" Subject: Recall: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue Date: Tue, 11 Jun 2002 12:12:20 +0200 Expiry-Date: Thu, 13 Jun 2002 12:11:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel-Angel Pallares-Lopez (ECE) would like to recall the message, "[AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue". From owner-aaa-wg@merit.edu Tue Jun 11 07:46: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 HAA18985 for ; Tue, 11 Jun 2002 07:46:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5F9691280; Tue, 11 Jun 2002 07:46:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64C7B91281; Tue, 11 Jun 2002 07:46:12 -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 E789191280 for ; Tue, 11 Jun 2002 07:46:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E8EBE5DDA8; Tue, 11 Jun 2002 07:46: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 4B03E5DD8C for ; Tue, 11 Jun 2002 07:46:06 -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 g5BBkei27067 for ; Tue, 11 Jun 2002 14:46:40 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 14:46:09 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 14:46:08 +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]: Edits to Diameter 11 to resolve vendor-specific commandcode issue Date: Tue, 11 Jun 2002 14:46:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653DC@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific commandcode issue Thread-Index: AcIRLsNCrBFI4iL0SzG1vzEaiidutQADppbQ From: To: Cc: , X-OriginalArrivalTime: 11 Jun 2002 11:46:08.0421 (UTC) FILETIME=[93723D50:01C2113D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA18985 Hi Johan, Just to play the devil's advocate, > If I were to define some messages to e.g. exchange state information > between AAA servers the contents of that message almost certainly would > depend on the implementation and would be useful to me but probably of > little use to anyone else. If you did the above, why would the proposed statement in the Diameter base: The extension MUST be documented through an IETF process. The documentation MUST describe interaction with Diameter peers that do not implement the extension. cause you problem? If you didn't document it, no one is going to come after you. John From owner-aaa-wg@merit.edu Tue Jun 11 08:30: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 IAA20209 for ; Tue, 11 Jun 2002 08:30:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85B939120F; Tue, 11 Jun 2002 08:30:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 519609126D; Tue, 11 Jun 2002 08:30:50 -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 4D7409120F for ; Tue, 11 Jun 2002 08:30:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A81C5DDCC; Tue, 11 Jun 2002 08:30:45 -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 9507E5DD8C for ; Tue, 11 Jun 2002 08:30:44 -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 g5BCVmUg014660; Tue, 11 Jun 2002 14:31:48 +0200 Message-ID: <3D05ED57.8060205@ipunplugged.com> Date: Tue, 11 Jun 2002 14:30:15 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: dlwarren@nortelnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific commandcode issue References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653DC@esebe004.NOE.Nokia.com> 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 John, with all due respect, I think you have it backwards. The question is not why the rule is not needed but why it is needed. As you hint at yourself, it will not be adhered to since it doesn't make sense to implementers. So far we have no explanation of why this rule is needed, only the AD's word that this is indeed the case. I do not see the benefit of making constraints that we don't expect to be followed, nor can I find any gain in claiming an implementation to be non-compliant if it behaves correctly towards other implementations. j john.loughney@nokia.com wrote: >Hi Johan, > >Just to play the devil's advocate, > >>If I were to define some messages to e.g. exchange state information >>between AAA servers the contents of that message almost certainly would >>depend on the implementation and would be useful to me but probably of >>little use to anyone else. >> > >If you did the above, why would the proposed statement in the Diameter >base: > > The extension MUST be documented through an IETF process. The > documentation MUST describe interaction with Diameter peers > that do not implement the extension. > >cause you problem? If you didn't document it, no one is going to come >after you. > >John > From owner-aaa-wg@merit.edu Tue Jun 11 08:40: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 IAA20614 for ; Tue, 11 Jun 2002 08:40:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56E7E9126D; Tue, 11 Jun 2002 08:40:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 248E891282; Tue, 11 Jun 2002 08:40:57 -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 1C9799126D for ; Tue, 11 Jun 2002 08:40:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2511F5DDD9; Tue, 11 Jun 2002 08:40:52 -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 CA9FC5DDCC for ; Tue, 11 Jun 2002 08:40:51 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user273.cisco.com [10.70.83.17]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id FAA06557; Tue, 11 Jun 2002 05:40:49 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Cc: , , "Randy Bush" Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific commandcode issue Date: Tue, 11 Jun 2002 05:40:42 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC653DC@esebe004.NOE.Nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > Hi Johan, > > Just to play the devil's advocate, > > > If I were to define some messages to e.g. exchange state information > > between AAA servers the contents of that message almost certainly would > > depend on the implementation and would be useful to me but probably of > > little use to anyone else. > > If you did the above, why would the proposed statement in the Diameter > base: > > The extension MUST be documented through an IETF process. The > documentation MUST describe interaction with Diameter peers > that do not implement the extension. > > cause you problem? If you didn't document it, no one is going to come > after you. Exactly. In fact, no one is going to come after you no matter what you do with/to Diameter (a fact that has been amply proved w/RADIUS - see RFC 2882). There are no "protocol cops". However, it seems to me that if someone _does_ evil, non-standard things w/Diameter and tries to claim to be following the standard, it should be pretty obvious. For example, if a vendor-specific request is sent to a box that doesn't support it, the resulting answer (same command code for easy identification) will have the E bit set and a result code of DIAMETER_COMMAND_UNSUPPORTED. How much simpler can you get? > > John > > From owner-aaa-wg@merit.edu Tue Jun 11 08:45: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 IAA20738 for ; Tue, 11 Jun 2002 08:45:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18C9691282; Tue, 11 Jun 2002 08:45:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BE6491283; Tue, 11 Jun 2002 08:45:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB3BD91282 for ; Tue, 11 Jun 2002 08:45:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E50B55DDD9; Tue, 11 Jun 2002 08:45: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 E4E425DD8C for ; Tue, 11 Jun 2002 08:45: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 g5BCjfi09530 for ; Tue, 11 Jun 2002 15:45:41 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 11 Jun 2002 15:45:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 15:45:14 +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]: 4 proposals for solving vendor specific commands Date: Tue, 11 Jun 2002 15:45:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653DF@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific commandcode issue Thread-Index: AcIRQ9ZklLl58+PARyOpgjVGxunehAAAFwUw From: To: X-OriginalArrivalTime: 11 Jun 2002 12:45:14.0999 (UTC) FILETIME=[D55F1870:01C21145] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA20738 Hi all, Let's approach this problem from a higher-level. I think that no matter what, folks will implement extensions. Having a paper trail, even on vendor specific commands, is useful. Whatever system is used for capturing the paper trail should be as straight forward as possible, so that folks do create paper trails. Additionally, technical reviews on extensions are not a bad thing. It seems that there are the following options for resolving this. 1) Solution: Do nothing. Result: the area directors will not let the Diameter progress. 2) Solution: prohibit vendor extensions. Result: extensions will be implemented anyway & no way to control them, no paper trail. 3) Solution: Mandate Informational RFCs on vendor extensions Result: May get paper trail, get control of specs, but still may result in folks not documenting anything 4) Solution: IANA registry, with pointer to further documentation Result: Will most likely get paper trail, may not have any way of preventing bad behavior. I think that that points 3 or 4 are the way forward. We need confirmation on which is the proper way forward from the chairs and area directors. My gut feeling is recommending Information RFCs (maybe not mandating them) is a good thing. Additionally, defining default behavior is needed. The default behavior being that Diameter peers should disregard unknown / unsupported vendor commands. Senders of unsupported commands are at fault. Comments? John From owner-aaa-wg@merit.edu Tue Jun 11 09:06: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 JAA21438 for ; Tue, 11 Jun 2002 09:06:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF30491287; Tue, 11 Jun 2002 09:06:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92E3391288; Tue, 11 Jun 2002 09:06: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 951FE91287 for ; Tue, 11 Jun 2002 09:06:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9D0E5DDE4; Tue, 11 Jun 2002 09:06:03 -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 138CF5DDD9 for ; Tue, 11 Jun 2002 09:06:03 -0400 (EDT) Received: (qmail 16070 invoked by uid 500); 11 Jun 2002 13:06:11 -0000 Date: Tue, 11 Jun 2002 08:06:11 -0500 From: David Frascone To: aaa-wg@merit.edu Cc: john.loughney@nokia.com, aboba@internaut.com, randy@psg.com Subject: Re: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes Message-ID: <20020611130610.GB12784@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, john.loughney@nokia.com, aboba@internaut.com, randy@psg.com References: <577066326047D41180AC00508B955DDA05ED2378@eestqnt104> <3D05BA63.8000702@ipunplugged.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D05BA63.8000702@ipunplugged.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I also feel that removing vendor specific applications would kill Diameter. On Tuesday, 11 Jun 2002, Johan Johansson wrote: > As do I. > > j > > Miguel-Angel Pallares-Lopez (ECE) wrote: > > >Hi, > > > >I fully support the opinions expressed in favour of keeping the support of > >vendor specific applications. > > > >Best regards, > >Miguel > > > > > > > -- David Frascone System going down at 5 p.m. to install scheduler bug. From owner-aaa-wg@merit.edu Tue Jun 11 09:25:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22672 for ; Tue, 11 Jun 2002 09:25:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26C5791288; Tue, 11 Jun 2002 09:25:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E85E89128D; Tue, 11 Jun 2002 09:25: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 E49F491288 for ; Tue, 11 Jun 2002 09:25:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE0405DDE6; Tue, 11 Jun 2002 09:25:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 829485DDD9 for ; Tue, 11 Jun 2002 09:25:40 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21831; Tue, 11 Jun 2002 07:25:48 -0600 (MDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BDPkb00676; Tue, 11 Jun 2002 15:25:46 +0200 (MEST) Date: Tue, 11 Jun 2002 06:25:39 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: 4 proposals for solving vendor specific commands In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC653DF@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 On Tue, 11 Jun 2002 john.loughney@nokia.com wrote: > 1) Solution: Do nothing. > 2) Solution: prohibit vendor extensions. > 3) Solution: Mandate Informational RFCs on vendor extensions > 4) Solution: IANA registry, with pointer to further documentation Experience with SLP extensions has shown that route '4' is a lot less painful than '3'. We have gotten extensions registered with IANA in under two weeks. The result is that those who want to interoperate can get the specification easily. Those who have vendor extensions and do not have years to spend on the IETF process can easily get their specifications published. Peer review is still possible on these specs, for example, on a mailing list dedicated to such discussion. Erik From owner-aaa-wg@merit.edu Tue Jun 11 09:27: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 JAA22788 for ; Tue, 11 Jun 2002 09:27:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6C349128D; Tue, 11 Jun 2002 09:27:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 885719128E; Tue, 11 Jun 2002 09:27:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A6CE9128D for ; Tue, 11 Jun 2002 09:27:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FFAF5DDE6; Tue, 11 Jun 2002 09:27:39 -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 E76325DDD9 for ; Tue, 11 Jun 2002 09:27:38 -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 g5BDQTd29188 for ; Tue, 11 Jun 2002 16:26:29 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Jun 2002 16:27:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 16:27:47 +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]: 4 proposals for solving vendor specific commands Date: Tue, 11 Jun 2002 16:27:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653E5@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: 4 proposals for solving vendor specific commands Thread-Index: AcIRS4J901YUJWYrTqOAugN9xbTbJQAACusw From: To: Cc: X-OriginalArrivalTime: 11 Jun 2002 13:27:47.0072 (UTC) FILETIME=[C6868800:01C2114B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22788 Hi Erik, > On Tue, 11 Jun 2002 john.loughney@nokia.com wrote: > > 1) Solution: Do nothing. > > 2) Solution: prohibit vendor extensions. > > 3) Solution: Mandate Informational RFCs on vendor extensions > > 4) Solution: IANA registry, with pointer to further documentation > > Experience with SLP extensions has shown that route '4' is a lot > less painful than '3'. We have gotten extensions registered with > IANA in under two weeks. > > The result is that those who want to interoperate can get the > specification easily. Those who have vendor extensions and do not > have years to spend on the IETF process can easily get their > specifications published. Peer review is still possible on these > specs, for example, on a mailing list dedicated to such discussion. Thanks for the input from a practical perspective. it is useful to have a reality check now and again. John From owner-aaa-wg@merit.edu Tue Jun 11 09:36: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 JAA23407 for ; Tue, 11 Jun 2002 09:36:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9FCD9128E; Tue, 11 Jun 2002 09:36:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A17159128F; Tue, 11 Jun 2002 09:36: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 8344A9128E for ; Tue, 11 Jun 2002 09:36:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86F4A5DDE6; Tue, 11 Jun 2002 09:36:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id 2ADA15DDB9 for ; Tue, 11 Jun 2002 09:36:50 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BDamv17724; Tue, 11 Jun 2002 09:36:48 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 09:36:48 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5BB@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Erik Guttman'" , john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: 4 proposals for solving vendor specific commands Date: Tue, 11 Jun 2002 09:36:48 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-aaa-wg@merit.edu Precedence: bulk I'll toss in the Megaco experience, which may or may not be acceptable to the IESG if they had the chance to make the decision again. We allow extensions to the Megaco protocol through packages. These are of two types, public and private. There is one IANA registry for all packages. Public packages must have publicly-accessible documentation somewhere (doesn't have to be IETF). Private packages just have a name and a contact. -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] Sent: Tuesday, June 11, 2002 9:26 AM To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: 4 proposals for solving vendor specific commands On Tue, 11 Jun 2002 john.loughney@nokia.com wrote: > 1) Solution: Do nothing. > 2) Solution: prohibit vendor extensions. > 3) Solution: Mandate Informational RFCs on vendor extensions > 4) Solution: IANA registry, with pointer to further documentation Experience with SLP extensions has shown that route '4' is a lot less painful than '3'. We have gotten extensions registered with IANA in under two weeks. The result is that those who want to interoperate can get the specification easily. Those who have vendor extensions and do not have years to spend on the IETF process can easily get their specifications published. Peer review is still possible on these specs, for example, on a mailing list dedicated to such discussion. Erik From owner-aaa-wg@merit.edu Tue Jun 11 10:19: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 KAA25593 for ; Tue, 11 Jun 2002 10:19:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4438A91296; Tue, 11 Jun 2002 10:17:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13BD991297; Tue, 11 Jun 2002 10:17: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 60C3591296 for ; Tue, 11 Jun 2002 10:17:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7747B5DDB9; Tue, 11 Jun 2002 10:17:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (dhcp3202.nanog25.merit.net [192.35.167.202]) by segue.merit.edu (Postfix) with ESMTP id 5CA085DD8C for ; Tue, 11 Jun 2002 10:17:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HmSh-0002HH-00; Tue, 11 Jun 2002 07:17:31 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Daniel Warren" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes References: Message-Id: Date: Tue, 11 Jun 2002 07:17:31 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I have to say that I am concerned by the proposal that John Loughney has > communicated here. It was my understanding that vendor specific extension > was exactly that - a facility whereby a vendor can include additional > commands to facilitate the extension of Diameter Base Protocol or Diameter > Applications to enhance their specific implementation. like most standards organizations, the ietf is about users' needs for multi-vendor inter-operability randy From owner-aaa-wg@merit.edu Tue Jun 11 10:21: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 KAA25706 for ; Tue, 11 Jun 2002 10:21:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D41E91293; Tue, 11 Jun 2002 10:21:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06B5E91294; Tue, 11 Jun 2002 10:21: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 ECF6691293 for ; Tue, 11 Jun 2002 10:21:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F4555DDB9; Tue, 11 Jun 2002 10:21:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (dhcp3202.nanog25.merit.net [192.35.167.202]) by segue.merit.edu (Postfix) with ESMTP id E7B495DD8C for ; Tue, 11 Jun 2002 10:21:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HmWx-0002Hn-00; Tue, 11 Jun 2002 07:21:55 -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]: Edits to Diameter 11 to resolve vendor-specific command code issue References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653D8@esebe004.NOE.Nokia.com> Message-Id: Date: Tue, 11 Jun 2002 07:21:55 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I think Randy, as Area Director, may need to speak to the concerns that > documenting extensions as an Information RFC may be too difficult. The > IESG has raised the issue that all Diameter extensions need a paper trail > & informational RFCs are the way to provide a paper trail in the IETF. warning: i suspect (but am not sure) the iesg will request it be a standards action, i.e. a standards track rfc, not info. the iesg has been down this road many times before, and tends to be pretty firm in this area. the iesg seems to think standards are about inter-operability. randy From owner-aaa-wg@merit.edu Tue Jun 11 10:23:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25775 for ; Tue, 11 Jun 2002 10:23:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35AE691291; Tue, 11 Jun 2002 10:23:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 032DD91294; Tue, 11 Jun 2002 10:23: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 CAEF391291 for ; Tue, 11 Jun 2002 10:23:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3EC25DDE5; Tue, 11 Jun 2002 10:23:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 276375DDB9 for ; Tue, 11 Jun 2002 10:23:43 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BENnA06873; Tue, 11 Jun 2002 16:23:49 +0200 (MEST) 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 g5BENlQ16880; Tue, 11 Jun 2002 15:23:47 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 15:23:51 +0100 Message-ID: From: "Daniel Warren" To: "'Randy Bush'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes Date: Tue, 11 Jun 2002 15:23:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21153.9B24F626" 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_01C21153.9B24F626 Content-Type: text/plain; charset="iso-8859-1" Agreed. Which is why vendor specific extensions of protocols should be defined by the vendor concerned and NOT be part of a standards process. It is also why vendor specific extensions should be defined in an entirely optional way so that they do not break the multi-vendor interoperability should they 'leak' into a multi-vendor environment. The text in the Diameter Base right now allows for both of the above statements to hold true. So isn't the solution to allow extensibility with that understanding rather than to restrict it? Dan -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: 11 June 2002 15:18 To: Warren, Daniel [MDN05:EP10:EXCH] Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes > I have to say that I am concerned by the proposal that John Loughney has > communicated here. It was my understanding that vendor specific extension > was exactly that - a facility whereby a vendor can include additional > commands to facilitate the extension of Diameter Base Protocol or Diameter > Applications to enhance their specific implementation. like most standards organizations, the ietf is about users' needs for multi-vendor inter-operability randy ------_=_NextPart_001_01C21153.9B24F626 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter = command- codes

Agreed.  Which is why vendor specific extensions = of protocols should be defined by the vendor concerned and NOT be part = of a standards process.

It is also why vendor specific extensions should be = defined in an entirely optional way so that they do not break the = multi-vendor interoperability should they 'leak' into a multi-vendor = environment.  The text in the Diameter Base right now allows for = both of the above statements to hold true.

So isn't the solution to allow extensibility with = that understanding rather than to restrict it?

Dan

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: 11 June 2002 15:18
To: Warren, Daniel [MDN05:EP10:EXCH]
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Issue: Removal of = vendor-specific Diameter
command- codes


> I have to say that I am concerned by the = proposal that John Loughney has
> communicated here.  It was my = understanding that vendor specific extension
> was exactly that - a facility whereby a vendor = can include additional
> commands to facilitate the extension of = Diameter Base Protocol or Diameter
> Applications to enhance their specific = implementation.

like most standards organizations, the ietf is about = users' needs for
multi-vendor inter-operability

randy

------_=_NextPart_001_01C21153.9B24F626-- From owner-aaa-wg@merit.edu Tue Jun 11 10:26: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 KAA25878 for ; Tue, 11 Jun 2002 10:26:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F07B91294; Tue, 11 Jun 2002 10:26:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C85491295; Tue, 11 Jun 2002 10:26: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 0479991294 for ; Tue, 11 Jun 2002 10:26:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C23E5DDE9; Tue, 11 Jun 2002 10:26:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id D5D9C5DDB9 for ; Tue, 11 Jun 2002 10:26:27 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BEQTv27538; Tue, 11 Jun 2002 10:26:30 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 10:26:29 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5BE@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Randy Bush'" , john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue Date: Tue, 11 Jun 2002 10:26:22 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-aaa-wg@merit.edu Precedence: bulk The SIP precedent is active right now. P-headers are Informational. See draft-tsvarea-sipchange-02.txt. -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Tuesday, June 11, 2002 10:22 AM To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue > I think Randy, as Area Director, may need to speak to the concerns that > documenting extensions as an Information RFC may be too difficult. The > IESG has raised the issue that all Diameter extensions need a paper trail > & informational RFCs are the way to provide a paper trail in the IETF. warning: i suspect (but am not sure) the iesg will request it be a standards action, i.e. a standards track rfc, not info. the iesg has been down this road many times before, and tends to be pretty firm in this area. the iesg seems to think standards are about inter-operability. randy From owner-aaa-wg@merit.edu Tue Jun 11 10:38: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 KAA26684 for ; Tue, 11 Jun 2002 10:38:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 994DF91295; Tue, 11 Jun 2002 10:38:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66C3491297; Tue, 11 Jun 2002 10:38: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 651AA91295 for ; Tue, 11 Jun 2002 10:38:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BDBD5DDB9; Tue, 11 Jun 2002 10:38:32 -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 B6E4D5DDEA for ; Tue, 11 Jun 2002 10:38:31 -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 g5BEdaUg018377; Tue, 11 Jun 2002 16:39:36 +0200 Message-ID: <3D060B4A.2080200@ipunplugged.com> Date: Tue, 11 Jun 2002 16:38:02 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Randy Bush Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653D8@esebe004.NOE.Nokia.com> 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 Randy Bush wrote: >>I think Randy, as Area Director, may need to speak to the concerns that >>documenting extensions as an Information RFC may be too difficult. The >>IESG has raised the issue that all Diameter extensions need a paper trail >>& informational RFCs are the way to provide a paper trail in the IETF. >> > >warning: i suspect (but am not sure) the iesg will request it be a standards >action, i.e. a standards track rfc, not info. the iesg has been down this >road many times before, and tends to be pretty firm in this area. the iesg >seems to think standards are about inter-operability. > Then again a vendor-specific extension is as far away as you can get from a standard and by definition have nothing to do with interoperability between vendors. I find it unreasonable that the IESG truly wants vendor-specific extensions turned into standards so there must be a huge misunderstanding hiding somewhere in all this lack of communication. j From owner-aaa-wg@merit.edu Tue Jun 11 11:05: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 LAA28135 for ; Tue, 11 Jun 2002 11:05:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BD6D991298; Tue, 11 Jun 2002 11:05:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88D3591299; Tue, 11 Jun 2002 11:05: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 3E19291298 for ; Tue, 11 Jun 2002 11:05:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53FCA5DDF0; Tue, 11 Jun 2002 11:05:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id ECE435DDB9 for ; Tue, 11 Jun 2002 11:05:18 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BF5Iv06467; Tue, 11 Jun 2002 11:05:18 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 11:05:18 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5C0@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Johan Johansson'" , Randy Bush Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue Date: Tue, 11 Jun 2002 11:05:11 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-aaa-wg@merit.edu Precedence: bulk Again, look at the SIP change process draft I cited in my previous message. The reason for IETF oversight is to protect the integrity of the protocol architecture. -----Original Message----- From: Johan Johansson [mailto:johanj@ipunplugged.com] Sent: Tuesday, June 11, 2002 10:38 AM To: Randy Bush Cc: john.loughney@nokia.com; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Randy Bush wrote: >>I think Randy, as Area Director, may need to speak to the concerns that >>documenting extensions as an Information RFC may be too difficult. The >>IESG has raised the issue that all Diameter extensions need a paper trail >>& informational RFCs are the way to provide a paper trail in the IETF. >> > >warning: i suspect (but am not sure) the iesg will request it be a standards >action, i.e. a standards track rfc, not info. the iesg has been down this >road many times before, and tends to be pretty firm in this area. the iesg >seems to think standards are about inter-operability. > Then again a vendor-specific extension is as far away as you can get from a standard and by definition have nothing to do with interoperability between vendors. I find it unreasonable that the IESG truly wants vendor-specific extensions turned into standards so there must be a huge misunderstanding hiding somewhere in all this lack of communication. j From owner-aaa-wg@merit.edu Tue Jun 11 12:14: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 MAA01075 for ; Tue, 11 Jun 2002 12:14:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ACB3D91299; Tue, 11 Jun 2002 12:14:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 720B19129A; Tue, 11 Jun 2002 12:14:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BC9891299 for ; Tue, 11 Jun 2002 12:14:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 665BA5DDF9; Tue, 11 Jun 2002 12:14:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 476D85DDD4 for ; Tue, 11 Jun 2002 12:14:16 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5BGEJQ07297; Tue, 11 Jun 2002 12:14:19 -0400 (EDT) Received: from mccap-1.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA21758; Tue, 11 Jun 2002 11:14:18 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GXJUFR-0000NO-00; Tue, 11 Jun 2002 12:14:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15622.8661.621324.152070@gargle.gargle.HOWL> Date: Tue, 11 Jun 2002 11:14:13 -0500 From: Pete McCann To: Randy Bush Cc: , Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue In-Reply-To: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653D8@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 Randy Bush writes: > warning: i suspect (but am not sure) the iesg will request it be a standards > action, i.e. a standards track rfc, not info. the iesg has been down this > road many times before, and tends to be pretty firm in this area. the iesg > seems to think standards are about inter-operability. I think that would pretty much kill the work going on now to define the Cx, Dx, and Sh interfaces in 3GPP. The protocols being defined for these interfaces could be considered precursors to an IETF-approved SIP-AAA application, and I suspect if they came before the IESG for approval they would be vetoed in favor of waiting for the completed SIP-AAA protocol. I understand that the current thinking from SIP is to tightly control the extension process with the goal of better interoperability, but I would argue that the Diameter suite, with its background in the RADIUS experience, is a different kind of animal. There has always been strong consensus among the working group to support a clean mechanism for vendor-specific (non-standards-track and even non-documented) extensibility. The usefulness of the Diameter base protocol will be severely impaired if these functions are removed. I daresay that 3GPP would be tempted to go define its own version of the Diameter protocol (let's call it Circumference, because it's a way around the IETF) to put these attributes back in. Philosophically, I do not really agree with the sentiment that extensions should be tightly controlled. I think the purpose of the IETF is to build communications infrastructure and then get out of the way, and allow end-to-end applications to experiment and develop on their own. That is how I view the Diameter base protocol. Should we go back and try to prohibit any non-standards-track UDP applications from being used on the Internet? I think not. -Pete From owner-aaa-wg@merit.edu Tue Jun 11 21:46: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 VAA19514 for ; Tue, 11 Jun 2002 21:46:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B15291214; Tue, 11 Jun 2002 21:46:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44A5A912A8; Tue, 11 Jun 2002 21:46: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 F051E91214 for ; Tue, 11 Jun 2002 21:46:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17EEF5DE08; Tue, 11 Jun 2002 21:46:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 4FB675DD9C for ; Tue, 11 Jun 2002 21:46:22 -0400 (EDT) Received: from cisco.com ([10.77.201.96]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA14681; Wed, 12 Jun 2002 07:15:08 +0530 (IST) Message-ID: <3D06A7F1.8D93DA2E@cisco.com> Date: Wed, 12 Jun 2002 07:16:25 +0530 From: Sakthidaran V X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: 4 proposals for solving vendor specific commands References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653DF@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi , I think 4 is the way to go and it would be efffective (from the generate_a_trail perspective) if we REQUIRE rather than RECOMMEND an information RFC . My 2 cents ... Thank you for your time . Regds Shakthi svadakey@cisco.com john.loughney@nokia.com wrote: > Hi all, > > Let's approach this problem from a higher-level. I think that no matter what, > folks will implement extensions. Having a paper trail, even on vendor specific > commands, is useful. Whatever system is used for capturing the paper trail > should be as straight forward as possible, so that folks do create paper trails. > Additionally, technical reviews on extensions are not a bad thing. > > It seems that there are the following options for resolving this. > > 1) Solution: Do nothing. > Result: the area directors will not let the Diameter progress. > > 2) Solution: prohibit vendor extensions. > Result: extensions will be implemented anyway & no way to control them, > no paper trail. > > 3) Solution: Mandate Informational RFCs on vendor extensions > Result: May get paper trail, get control of specs, but still may result in > folks not documenting anything > > 4) Solution: IANA registry, with pointer to further documentation > Result: Will most likely get paper trail, may not have any way of preventing bad > behavior. > > I think that that points 3 or 4 are the way forward. We need confirmation on which > is the proper way forward from the chairs and area directors. > > My gut feeling is recommending Information RFCs (maybe not mandating them) is a good thing. > Additionally, defining default behavior is needed. > > The default behavior being that Diameter peers should disregard unknown / unsupported vendor > commands. Senders of unsupported commands are at fault. > > Comments? > John -- From owner-aaa-wg@merit.edu Wed Jun 12 03:02:16 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 DAA19471 for ; Wed, 12 Jun 2002 03:02:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CDE791223; Wed, 12 Jun 2002 03:02:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48E65912AC; Wed, 12 Jun 2002 03:02: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 15FA291223 for ; Wed, 12 Jun 2002 03:02:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DDB85DDF9; Wed, 12 Jun 2002 03:02:28 -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 5F3CD5DDB7 for ; Wed, 12 Jun 2002 03:02:27 -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 g5C74HW26796 for ; Wed, 12 Jun 2002 10:04:17 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Jun 2002 10:02:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 10:02:35 +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]: Edits to Diameter 11 to resolve vendor-specific command code issue Date: Wed, 12 Jun 2002 10:02:34 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC653EF@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Thread-Index: AcIRVXsHoLdgBBqqTxCSYPvxv4n7yQAiTH4A From: To: , Cc: X-OriginalArrivalTime: 12 Jun 2002 07:02:35.0614 (UTC) FILETIME=[216FA7E0:01C211DF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA19471 Hi Tom, > The SIP precedent is active right now. P-headers are > Informational. See draft-tsvarea-sipchange-02.txt. I agree that SIP can be used as a precedent. Can we move forward with the proposal of creating informational rfcs? My feeling is that not all Diameter extensions (vendor-specific) are meant as standards, so in my opinion, a paper trail is what is needed. John > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Tuesday, June 11, 2002 10:22 AM > To: john.loughney@nokia.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific > command code issue > > warning: i suspect (but am not sure) the iesg will request it be a standards > action, i.e. a standards track rfc, not info. the iesg has been down this > road many times before, and tends to be pretty firm in this area. the iesg > seems to think standards are about inter-operability. > > randy > > From owner-aaa-wg@merit.edu Wed Jun 12 03:34:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19776 for ; Wed, 12 Jun 2002 03:34:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D85491289; Wed, 12 Jun 2002 03:34:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CFAA912AC; Wed, 12 Jun 2002 03:34: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 3EDEE91289 for ; Wed, 12 Jun 2002 03:34:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 745A55DDB5; Wed, 12 Jun 2002 03:34:54 -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 CC4A15DD9C for ; Wed, 12 Jun 2002 03:34:53 -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 g5C7ZSi16201 for ; Wed, 12 Jun 2002 10:35:28 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Jun 2002 10:35:02 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 10:35:11 +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 IETF Standard extensions vs. Vendor extensions Date: Wed, 12 Jun 2002 10:35:01 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E4E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue: Removal of vendor-specific Diameter command-codes Thread-Index: AcIR0P1m7BMGkxUaTriJb8O+Ic4cGwAEcZsA X-Priority: 1 Importance: high From: To: Cc: , X-OriginalArrivalTime: 12 Jun 2002 07:35:11.0321 (UTC) FILETIME=[AF20DC90:01C211E3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA19776 Hi all, There seems to be some misunderstanding in the recent discussions about the role of Diameter extensibility. I believe there are 2 kinds of extensions: (1) Public, IETF Standard extensions (2) Private, vendor extensions For (1) a standards track document is needed, in my opinion. For (2) I think a good way forward would be an IANA registry, with documentation needed, and a strong suggestion for an IETF informational document. The reason being is that we want to keep track of how vendors are extending Diameter and an Informational document would help the organization proposing the vendor extension to ensure they are doing the right thing. If my above analysis of the situation is correct, I can add explanatory text to section 1.2 & chapter 11. I would be happy to get AD acceptance on this, at least to be able to bring this to the IESG. thanks, John From owner-aaa-wg@merit.edu Wed Jun 12 06:39: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 GAA21935 for ; Wed, 12 Jun 2002 06:39:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE583912AD; Wed, 12 Jun 2002 06:40:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99C52912AE; Wed, 12 Jun 2002 06:40: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 718C3912AD for ; Wed, 12 Jun 2002 06:40:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A850F5DE31; Wed, 12 Jun 2002 06:40:04 -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 0BB405DE29 for ; Wed, 12 Jun 2002 06:40:04 -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 g5CAcrd17084 for ; Wed, 12 Jun 2002 13:38:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Jun 2002 13:40:10 +0300 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 13:40:10 +0300 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 18:39:46 +0800 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]: Issue: Vague words in Base-11 section 2.8 Date: Wed, 12 Jun 2002 18:37:29 +0800 Message-ID: Thread-Topic: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific commandcode issue Thread-Index: AcIRQ9ZklLl58+PARyOpgjVGxunehAAAFwUwAC25TaA= From: To: X-OriginalArrivalTime: 12 Jun 2002 10:39:46.0730 (UTC) FILETIME=[789628A0:01C211FD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA21935 Submitter name: Liu Qing Submitter email address: qing.roger.liu@nokia.com Date first submitted: 2002-06-12 Reference: Document: base-11 Comment type: T Priority: 1 Section: 2.8 Rationale/Explanation of issue: The draft says: 'A stateful agent is one that maintains session state information;', but it does not refer to the details of 'session state information'. In fact, we are obliged to provide two kinds of session state information: 1. for those 'STATE_MAINTAINED' sessions, 2. for those 'NO_STATE_MAINTAINED' sessions which the proxy still wants to limit the resources authorized. Requested change: From owner-aaa-wg@merit.edu Wed Jun 12 08:13:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24471 for ; Wed, 12 Jun 2002 08:13:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 33AA2912B6; Wed, 12 Jun 2002 08:13:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F14B3912B7; Wed, 12 Jun 2002 08:13: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 037D8912B6 for ; Wed, 12 Jun 2002 08:13:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40C105DDB7; Wed, 12 Jun 2002 08:13:47 -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 880395DE2F for ; Wed, 12 Jun 2002 08:13:46 -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 g5CCEhUg004584; Wed, 12 Jun 2002 14:14:44 +0200 Message-ID: <3D073AE0.2000207@ipunplugged.com> Date: Wed, 12 Jun 2002 14:13:20 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu, randy@psg.com, mankin@isi.edu Subject: Re: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E4E@esebe004.NOE.Nokia.com> 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 john.loughney@nokia.com wrote: >about the role of Diameter extensibility. I believe there are >2 kinds of extensions: > >(1) Public, IETF Standard extensions >(2) Private, vendor extensions > >For (1) a standards track document is needed, in my opinion. > This is undisputable and I doubt that it would be an IETF extension otherwise. >For (2) I think a good way forward would be an IANA registry, >with documentation needed, and a strong suggestion for an IETF >informational document. The reason being is that we want >to keep track of how vendors are extending Diameter and >an Informational document would help the organization proposing >the vendor extension to ensure they are doing the right thing. > >If my above analysis of the situation is correct, I can add explanatory >text to section 1.2 & chapter 11. > >I would be happy to get AD acceptance on this, at least to be able >to bring this to the IESG. > I maintain that anything that is vendor-specific is outside the scope of IETF, but if this is the only way forward I can live with this being added to the text. j From owner-aaa-wg@merit.edu Wed Jun 12 08:54: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 IAA26059 for ; Wed, 12 Jun 2002 08:54:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D6A29912DB; Wed, 12 Jun 2002 08:54:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DD67912CB; Wed, 12 Jun 2002 08:54:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43F27912DC for ; Wed, 12 Jun 2002 08:54:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D4D05DDB5; Wed, 12 Jun 2002 08:54:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 530945DD8C for ; Wed, 12 Jun 2002 08:54:10 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CCrpu13853; Wed, 12 Jun 2002 14:53:52 +0200 (MEST) 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 g5CCrnS14709; Wed, 12 Jun 2002 13:53:49 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:53:57 +0100 Message-ID: From: "Daniel Warren" To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Cc: randy@psg.com, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions Date: Wed, 12 Jun 2002 13:53:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21210.32C6B93A" 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_01C21210.32C6B93A Content-Type: text/plain; charset="iso-8859-1" I am still slightly confused. In extension type (2), John has described it as 'Private, vendor extensions'. I think the significant word here is 'Private' - if, to include a private extension, there is a requirement to provide an informational RFC and register it with IANA, that sounds more like a public extension to me. If, for example, Nokia develops a proprietary extension for their Diameter implementation, what is to stop every other vendor from implementing it as well, once it is an informational RFC? Basically, the only difference between extension type (1) and extension type (2) will be in the way it is documented. If we do take this approach, we should probably remove vendor-id and vendor extentions completely (since IANA could now manage the name space) and prohibit all forms of extension that are not put through IETF. This does mean that there is no motivation for vendors to innovate using Diameter, and little possibility for the customers of vendors to be able to obtain any form of differantiation between suppliers. I didn't think that was the intention or the ethos of Diameter as a protocol, but it appears I may have been wrong. Dan -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: 12 June 2002 08:35 To: aaa-wg@merit.edu Cc: randy@psg.com; mankin@isi.edu Subject: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Importance: High Hi all, There seems to be some misunderstanding in the recent discussions about the role of Diameter extensibility. I believe there are 2 kinds of extensions: (1) Public, IETF Standard extensions (2) Private, vendor extensions For (1) a standards track document is needed, in my opinion. For (2) I think a good way forward would be an IANA registry, with documentation needed, and a strong suggestion for an IETF informational document. The reason being is that we want to keep track of how vendors are extending Diameter and an Informational document would help the organization proposing the vendor extension to ensure they are doing the right thing. If my above analysis of the situation is correct, I can add explanatory text to section 1.2 & chapter 11. I would be happy to get AD acceptance on this, at least to be able to bring this to the IESG. thanks, John ------_=_NextPart_001_01C21210.32C6B93A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor = extensions

I am still slightly confused.  In extension type = (2), John has described it as 'Private, vendor extensions'.  I = think the significant word here is 'Private' - if, to include a private = extension, there is a requirement to provide an informational RFC and = register it with IANA, that sounds more like a public extension to = me.  If, for example, Nokia develops a proprietary extension for = their Diameter implementation, what is to stop every other vendor from = implementing it as well, once it is an informational RFC?  = Basically, the only difference between extension type (1) and extension = type (2) will be in the way it is documented.

If we do take this approach, we should probably = remove vendor-id and vendor extentions completely (since IANA could now = manage the name space) and prohibit all forms of extension that are not = put through IETF.  This does mean that there is no motivation for = vendors to innovate using Diameter, and little possibility for the = customers of vendors to be able to obtain any form of differantiation = between suppliers.  I didn't think that was the intention or the = ethos of Diameter as a protocol, but it appears I may have been = wrong.

Dan

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: 12 June 2002 08:35
To: aaa-wg@merit.edu
Cc: randy@psg.com; mankin@isi.edu
Subject: [AAA-WG]: Diameter IETF Standard extensions = vs. Vendor
extensions
Importance: High


Hi all,

There seems to be some misunderstanding in the recent = discussions
about the role of Diameter extensibility.  I = believe there are
2 kinds of extensions:

(1) Public, IETF Standard extensions
(2) Private, vendor extensions

For (1) a standards track document is needed, in my = opinion.

For (2) I think a good way forward would be an IANA = registry,
with documentation needed, and a strong suggestion = for an IETF
informational document.  The reason being is = that we want
to keep track of how vendors are extending Diameter = and
an Informational document would help the = organization proposing
the vendor extension to ensure they are doing the = right thing.

If my above analysis of the situation is correct, I = can add explanatory
text to section 1.2 & chapter 11.

I would be happy to get AD acceptance on this, at = least to be able
to bring this to the IESG.

thanks,
John

------_=_NextPart_001_01C21210.32C6B93A-- From owner-aaa-wg@merit.edu Wed Jun 12 10:39: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 KAA29933 for ; Wed, 12 Jun 2002 10:39:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BDE76912C2; Wed, 12 Jun 2002 10:40:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 891BE912E7; Wed, 12 Jun 2002 10:40: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 8592C912C2 for ; Wed, 12 Jun 2002 10:40:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5C815DE38; Wed, 12 Jun 2002 10:40:00 -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 BFB2A5DDB7 for ; Wed, 12 Jun 2002 10:39:59 -0400 (EDT) Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA15402; Wed, 12 Jun 2002 15:40:07 +0100 (BST) From: Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 12 Jun 2002 15:40:09 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jun 2002 15:40:12 +0100 Message-Id: <671F9BA1F495D4118E8000A0C9E5CA4A038B6C8D@Highgate.vfl.vodafone> To: dlwarren@nortelnetworks.com, john.loughney@nokia.com, aaa-wg@merit.edu Cc: randy@psg.com, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions Date: Wed, 12 Jun 2002 15:40:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Dear All, I agree with Dan. I also think the words "public" and "private" are slightly mis-used here. 3GPP could be considered a "private vendor" but at the same time, the technical specifications they produce are already publicly available (http:// www.3gpp.org.ftp/ftp/Specs ). So why should 3GPP, after producing their publicly available technical specifications, have to replicate their work by producing informational RFCs? They more than likely will not; which would be preferred as it saves duplication which is always bad in standards. But if all that is needed is a paper trail, why not include other standards bodies documents, not just informational IETF RFCs, as sufficient documentation for vendor specific extensions? Cheers, Nick (a "newbie") -----Original Message----- From: Daniel Warren [mailto:dlwarren@nortelnetworks.com] Sent: 12 June 2002 1:54pm To: 'john.loughney@nokia.com'; aaa-wg@merit.edu Cc: randy@psg.com; mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions I am still slightly confused. In extension type (2), John has described it as 'Private, vendor extensions'. I think the significant word here is 'Private' - if, to include a private extension, there is a requirement to provide an informational RFC and register it with IANA, that sounds more like a public extension to me. If, for example, Nokia develops a proprietary extension for their Diameter implementation, what is to stop every other vendor from implementing it as well, once it is an informational RFC? Basically, the only difference between extension type (1) and extension type (2) will be in the way it is documented. If we do take this approach, we should probably remove vendor-id and vendor extentions completely (since IANA could now manage the name space) and prohibit all forms of extension that are not put through IETF. This does mean that there is no motivation for vendors to innovate using Diameter, and little possibility for the customers of vendors to be able to obtain any form of differantiation between suppliers. I didn't think that was the intention or the ethos of Diameter as a protocol, but it appears I may have been wrong. Dan -----Original Message----- From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com ] Sent: 12 June 2002 08:35 To: aaa-wg@merit.edu Cc: randy@psg.com; mankin@isi.edu Subject: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Importance: High Hi all, There seems to be some misunderstanding in the recent discussions about the role of Diameter extensibility. I believe there are 2 kinds of extensions: (1) Public, IETF Standard extensions (2) Private, vendor extensions For (1) a standards track document is needed, in my opinion. For (2) I think a good way forward would be an IANA registry, with documentation needed, and a strong suggestion for an IETF informational document. The reason being is that we want to keep track of how vendors are extending Diameter and an Informational document would help the organization proposing the vendor extension to ensure they are doing the right thing. If my above analysis of the situation is correct, I can add explanatory text to section 1.2 & chapter 11. I would be happy to get AD acceptance on this, at least to be able to bring this to the IESG. thanks, John From owner-aaa-wg@merit.edu Wed Jun 12 10:50: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 KAA00176 for ; Wed, 12 Jun 2002 10:50:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2FB13912F7; Wed, 12 Jun 2002 10:50:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABF18912FD; Wed, 12 Jun 2002 10:50: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 E8DA1912F7 for ; Wed, 12 Jun 2002 10:50:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 30B4A5DE38; Wed, 12 Jun 2002 10:50:12 -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 844605DE41 for ; Wed, 12 Jun 2002 10:50:11 -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 g5CEoKmG017361; Wed, 12 Jun 2002 16:50:20 +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 M3J384Y5; Wed, 12 Jun 2002 16:50:19 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 16:50:19 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED23A5@eestqnt104> X-Sybari-Trust: 25671885 2a03b045 623d418c 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'Johan Johansson'" , john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions Date: Wed, 12 Jun 2002 16:50:15 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA00176 Hi, (1) is non-arguable. (2) John, how do you think this should work? Two examples: Let's suppose that an external Standards Development Organization develops a vendor-specific extension of Diameter (as has happened in 3GPP). What would 3GPP request IANA to register? The command-codes, AVP codes and result codes + a reference to the appropriate documentation (i.e. a 3GPP specification)? In this case the documentation would be publicly available. For the 3GPP case, I am not sure that an Informational Draft could be accepted by the IESG, on the basis that it can be considered that it collides with future work in the AAA WG. A different example is a vendor-specific extension, where the vendor is a manufacturer, not a Standards Development Organization. I guess that the vendor would need to register with IANA the same codes as in previous example. The difference here is that the documentation of the specification may well be something that the vendor does not want to make public. A possible solution to this could be not to mandate such pointer to documentation. In either case, what is the usefulness of this? I mean, when using a Vendor-Id, it should be (as it is with current text) the vendor's responsibility to manage its own namespaces for commands, AVPs and result codes. I would like to understand why IETF may want to know how vendors are using/extending Diameter. BR/Miguel -----Original Message----- From: Johan Johansson [mailto:johanj@ipunplugged.com] Sent: miércoles, 12 de junio de 2002 14:13 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu; randy@psg.com; mankin@isi.edu Subject: Re: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions john.loughney@nokia.com wrote: >about the role of Diameter extensibility. I believe there are >2 kinds of extensions: > >(1) Public, IETF Standard extensions >(2) Private, vendor extensions > >For (1) a standards track document is needed, in my opinion. > This is undisputable and I doubt that it would be an IETF extension otherwise. >For (2) I think a good way forward would be an IANA registry, >with documentation needed, and a strong suggestion for an IETF >informational document. The reason being is that we want >to keep track of how vendors are extending Diameter and >an Informational document would help the organization proposing >the vendor extension to ensure they are doing the right thing. > >If my above analysis of the situation is correct, I can add explanatory >text to section 1.2 & chapter 11. > >I would be happy to get AD acceptance on this, at least to be able >to bring this to the IESG. > I maintain that anything that is vendor-specific is outside the scope of IETF, but if this is the only way forward I can live with this being added to the text. j From owner-aaa-wg@merit.edu Wed Jun 12 10:54:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00326 for ; Wed, 12 Jun 2002 10:54:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 657E2912F2; Wed, 12 Jun 2002 10:54:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38A0C912F4; Wed, 12 Jun 2002 10:54: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 35092912F2 for ; Wed, 12 Jun 2002 10:54:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 75B0F5DE38; Wed, 12 Jun 2002 10:54:44 -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 543A85DDB7 for ; Wed, 12 Jun 2002 10:54:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17I9WO-000C1Z-00; Wed, 12 Jun 2002 07:54:53 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue References: <0C1353ABB1DEB74DB067ADFF749C4EEFC653EF@esebe004.NOE.Nokia.com> Message-Id: Date: Wed, 12 Jun 2002 07:54:53 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > My feeling is that not all Diameter extensions (vendor-specific) > are meant as standards, so in my opinion, a paper trail is what is > needed. lack of a paper trail is a show-stopper. whether it needs to be standard track, i can explore once things are in sufficient shape that i won't get an explosion in my face when the current we-can-do-whatever-we-want is seen. and another standards body wanting to use an ietf standard and modify it in arbitrary ways because they don't want to follow ietf process will be met with a stone wall at best. note how carefully the ietf does not step on the ieee's ethernet standards (to get our jumbo frames in), the itu on sdh/sonet, ... randy From owner-aaa-wg@merit.edu Wed Jun 12 11:24: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 LAA01195 for ; Wed, 12 Jun 2002 11:24:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE33F91229; Wed, 12 Jun 2002 11:24:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73DB5912F5; Wed, 12 Jun 2002 11:24: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 6662791229 for ; Wed, 12 Jun 2002 11:24:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E79415DE43; Wed, 12 Jun 2002 11:24:50 -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 161A35DDB7 for ; Wed, 12 Jun 2002 11:24: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 g5CFPOi01331 for ; Wed, 12 Jun 2002 18:25:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Jun 2002 18:24:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 18:24: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]: Edits to Diameter 11 to resolve vendor-specific command code issue Date: Wed, 12 Jun 2002 18:24:57 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E53@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Thread-Index: AcISISXcSHexuF2cQiGOLgWMhEu2wwAAu5iQ From: To: Cc: X-OriginalArrivalTime: 12 Jun 2002 15:24:58.0684 (UTC) FILETIME=[501B1FC0:01C21225] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01195 Randy, > > My feeling is that not all Diameter extensions (vendor-specific) > > are meant as standards, so in my opinion, a paper trail is what is > > needed. > > lack of a paper trail is a show-stopper. whether it needs to be > standard track, i can explore once things are in sufficient shape > that i won't get an explosion in my face when the current > we-can-do-whatever-we-want is seen. The current "we-can-do-whatever-we-want" is not really the intention of the draft, I think that there is information in the document, but it is not organized well. I will pull together the info and then we can go forward. > and another standards body wanting to use an ietf standard and > modify it in arbitrary ways because they don't want to follow ietf > process will be met with a stone wall at best. note how carefully > the ietf does not step on the ieee's ethernet standards (to get our > jumbo frames in), the itu on sdh/sonet, ... Understood. I think that on this subject, it is good to engage in constructive discussion between the SDOs. John From owner-aaa-wg@merit.edu Wed Jun 12 11:40: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 LAA01941 for ; Wed, 12 Jun 2002 11:40:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1438C912F5; Wed, 12 Jun 2002 11:40:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5A07912F8; Wed, 12 Jun 2002 11:40: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 AD907912F5 for ; Wed, 12 Jun 2002 11:40:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E519A5DE34; Wed, 12 Jun 2002 11:40:20 -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 46E7F5DDB7 for ; Wed, 12 Jun 2002 11:40:20 -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 g5CFgAW11219 for ; Wed, 12 Jun 2002 18:42:10 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Jun 2002 18:40:28 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 18:40:28 +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]: Edits to Diameter 11 to resolve vendor-specific command code issue Date: Wed, 12 Jun 2002 18:40:28 +0300 Message-ID: <07A6D72550C5E0459DE676439EE53846E32B83@esebe012.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Thread-Index: AcISIUQTk3qJT1wfSRefStCI63lo1gAA4WRQ From: To: X-OriginalArrivalTime: 12 Jun 2002 15:40:28.0632 (UTC) FILETIME=[7A65ED80:01C21227] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01941 Hello, Vendor-specific extensions to Diameter are not meant to modify a standard. The intention is that vendor-specific extensions use and support fully IETF-standard Diameter Base Protocol. The vendor-specific extensions do not modify anything that is defined in Diameter Base Protocol standard. The current Base Protocol draft specifies a standard way to make the extensions. It also defines means that ensure that the communicating entities know what extensions, if any, are supported at a given time. As I have understand it, the requirement for the extensibility is also defined in RFC 2989, Criteria for Evaluating AAA Protocols for Network Access. I'm a bit afraid that if it is not allowed to standardize how to make vendor-specific extensions, the vendors will make the extensions in ad-hoc ways -- causing interoperability problems galore. Best Regards, Mikko From owner-aaa-wg@merit.edu Wed Jun 12 11:46: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 LAA02108 for ; Wed, 12 Jun 2002 11:46:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9520491301; Wed, 12 Jun 2002 11:43:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A6BF91309; Wed, 12 Jun 2002 11:43: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 397E991301 for ; Wed, 12 Jun 2002 11:43:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D8C85DE34; Wed, 12 Jun 2002 11:43:44 -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 D72255DDB7 for ; Wed, 12 Jun 2002 11:43:43 -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 g5CFhqmG004222; Wed, 12 Jun 2002 17:43:52 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M3J39HDS; Wed, 12 Jun 2002 17:43:52 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 17:43:52 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED23AC@eestqnt104> X-Sybari-Trust: 582edb9d 2a03b045 623d418c 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'mikko.aittola@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific com mand code issue Date: Wed, 12 Jun 2002 17:43:49 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02108 Hi, I agree with Mikko. The vendor extensions we are thinking on fully respect the base protocol. BR/Miguel -----Original Message----- From: mikko.aittola@nokia.com [mailto:mikko.aittola@nokia.com] Sent: miércoles, 12 de junio de 2002 17:40 To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue Hello, Vendor-specific extensions to Diameter are not meant to modify a standard. The intention is that vendor-specific extensions use and support fully IETF-standard Diameter Base Protocol. The vendor-specific extensions do not modify anything that is defined in Diameter Base Protocol standard. The current Base Protocol draft specifies a standard way to make the extensions. It also defines means that ensure that the communicating entities know what extensions, if any, are supported at a given time. As I have understand it, the requirement for the extensibility is also defined in RFC 2989, Criteria for Evaluating AAA Protocols for Network Access. I'm a bit afraid that if it is not allowed to standardize how to make vendor-specific extensions, the vendors will make the extensions in ad-hoc ways -- causing interoperability problems galore. Best Regards, Mikko From owner-aaa-wg@merit.edu Wed Jun 12 11:46:48 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 LAA02148 for ; Wed, 12 Jun 2002 11:46:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 60E08912FA; Wed, 12 Jun 2002 11:44:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3D339130E; Wed, 12 Jun 2002 11:44: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 D6680912FA for ; Wed, 12 Jun 2002 11:44:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2436C5DE34; Wed, 12 Jun 2002 11:44:46 -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 768C35DDB7 for ; Wed, 12 Jun 2002 11:44:45 -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 g5CFkZW12661 for ; Wed, 12 Jun 2002 18:46:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Jun 2002 18:44:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 18:44:53 +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 IETF Standard extensions vs. Vendor extensions Date: Wed, 12 Jun 2002 18:44:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65419@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Thread-Index: AcISIHsQ2RQF5mAyQSOZZ5NnLb4cpgABw5bA From: To: , Cc: X-OriginalArrivalTime: 12 Jun 2002 15:44:53.0856 (UTC) FILETIME=[187BE600:01C21228] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02148 Hi Miguel, > (1) is non-arguable. > > (2) John, how do you think this should work? Two examples: > > Let's suppose that an external Standards Development > Organization develops a vendor-specific extension of Diameter > (as has happened in 3GPP). What would 3GPP request IANA to > register? The command-codes, AVP codes and result codes + a > reference to the appropriate documentation (i.e. a 3GPP > specification)? In this case the documentation would be > publicly available. For the 3GPP case, I am not sure that an > Informational Draft could be accepted by the IESG, on the > basis that it can be considered that it collides with future > work in the AAA WG. 3GPP is working on informational RFCs for SIP in release 5. This is not a bad precidence. SDOs and IETF working this way would save most of us a lot of agony. > A different example is a vendor-specific extension, where the > vendor is a manufacturer, not a Standards Development > Organization. I guess that the vendor would need to register > with IANA the same codes as in previous example. The > difference here is that the documentation of the > specification may well be something that the vendor does not > want to make public. A possible solution to this could be not > to mandate such pointer to documentation. This could / should be done by a simple IANA registry, with documentation provided at the time of registry. > In either case, what is the usefulness of this? I mean, when > using a Vendor-Id, it should be (as it is with current text) > the vendor's responsibility to manage its own namespaces for > commands, AVPs and result codes. I would like to understand > why IETF may want to know how vendors are using/extending Diameter. The reason being is that the IETF is concerned about end-user experience over the Internet. Vendor extensions should not break the protocol, nor harm the end-users. I think the IESG is concerned based on past experiences. John From owner-aaa-wg@merit.edu Wed Jun 12 11:47: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 LAA02178 for ; Wed, 12 Jun 2002 11:47:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C7939130C; Wed, 12 Jun 2002 11:44:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0949B91310; Wed, 12 Jun 2002 11:44: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 5A3E89130C for ; Wed, 12 Jun 2002 11:44:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 919515DE34; Wed, 12 Jun 2002 11:44:46 -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 6BFC85DDB7 for ; Wed, 12 Jun 2002 11:44:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17IAIo-000DaP-00; Wed, 12 Jun 2002 08:44:54 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Daniel Warren" Cc: "'john.loughney@nokia.com'" , aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions References: Message-Id: Date: Wed, 12 Jun 2002 08:44:54 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I am still slightly confused. In extension type (2), John has described > it as 'Private, vendor extensions'. I think the significant word here is > 'Private' - if, to include a private extension, there is a requirement to > provide an informational RFC and register it with IANA, that sounds more > like a public extension to me. If, for example, Nokia develops a > proprietary extension for their Diameter implementation, what is to stop > every other vendor from implementing it as well, once it is an > informational RFC? Basically, the only difference between extension type > (1) and extension type (2) will be in the way it is documented. > > If we do take this approach, we should probably remove vendor-id and > vendor extentions completely (since IANA could now manage the name space) > and prohibit all forms of extension that are not put through IETF. This > does mean that there is no motivation for vendors to innovate using > Diameter, and little possibility for the customers of vendors to be able > to obtain any form of differantiation between suppliers. I didn't think > that was the intention or the ethos of Diameter as a protocol, but it > appears I may have been wrong. a vendor may do whatever they wish. the point is what they can do and still call it diameter. when they call it diameter, the customer has a legitimate expectiation that vendor A's diameter will inter-operate with vendor B's diameter. that is what standards are all about. randy From owner-aaa-wg@merit.edu Wed Jun 12 11:58:48 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 LAA02702 for ; Wed, 12 Jun 2002 11:58:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D2E4912C4; Wed, 12 Jun 2002 11:59:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E899912C8; Wed, 12 Jun 2002 11:58: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 0B460912C4 for ; Wed, 12 Jun 2002 11:58:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 400F85DE34; Wed, 12 Jun 2002 11:58:55 -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 61DF05DDB7 for ; Wed, 12 Jun 2002 11:58:54 -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 g5CFxSi17318 for ; Wed, 12 Jun 2002 18:59:28 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Jun 2002 18:59:02 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 18:59: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: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Date: Wed, 12 Jun 2002 18:59:02 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6541D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Thread-Index: AcISKQzsyLmkrqwmSH29FH/RGptrrAAAE8GA From: To: , Cc: , X-OriginalArrivalTime: 12 Jun 2002 15:59:02.0497 (UTC) FILETIME=[12503D10:01C2122A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02702 Hi Randy, > a vendor may do whatever they wish. the point is what they can do and > still call it diameter. when they call it diameter, the customer has > a legitimate expectiation that vendor A's diameter will inter-operate > with vendor B's diameter. that is what standards are all about. I agree. I propose the following for vendor extensions: We need a way for vendors to 'register' their extensions, so that there is some paper trail. In the case when a vendor extensions is marked as mandatory, any failures MUST be the fault of the sending side (the side which sends extension marked as mandatory). Also, the system MUST be able to work without the non-standard extension. In summary, all vendor extensions MUST NOT harm interoperability. I propose to add this kind of text to 1.2 'Approach to Extensibility' and to make the text in the IANA section more bullet-proof. Also, a recommendation that vendors submit documentation for consideration as Informational RFCs may be a good recommendation as well. John From owner-aaa-wg@merit.edu Wed Jun 12 12:02: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 MAA02871 for ; Wed, 12 Jun 2002 12:02:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 25301912C8; Wed, 12 Jun 2002 12:02:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E29C7912F9; Wed, 12 Jun 2002 12:02: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 8D160912C8 for ; Wed, 12 Jun 2002 12:02:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6A1E5DE34; Wed, 12 Jun 2002 12:02:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id EFEC35DDB7 for ; Wed, 12 Jun 2002 12:02:11 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CG2Bu13713; Wed, 12 Jun 2002 18:02:12 +0200 (MEST) 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 g5CG29Q13535; Wed, 12 Jun 2002 17:02:10 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 17:02:09 +0100 Message-ID: From: "Daniel Warren" To: "'Randy Bush'" Cc: "'john.loughney@nokia.com'" , aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions Date: Wed, 12 Jun 2002 17:02:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2122A.800DD7F4" 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_01C2122A.800DD7F4 Content-Type: text/plain; charset="iso-8859-1" > a vendor may do whatever they wish. the point is what they can do and > still call it diameter. when they call it diameter, the customer has > a legitimate expectiation that vendor A's diameter will inter-operate > with vendor B's diameter. that is what standards are all about. From what you say here, it sounds to me that we actually have three cases rather than the two that John described. There is the Public, IETF standardised extensions and 'Private', vendor extensions, and then there is this third 'a vendor may do whatever they wish' extension, just so long as they don't call it Diameter. My continued confusion is that if you accept that 'a vendor may do whatever they wish', and whatever they wish is defined in a way that says 'if you don't understand it, ignore it' and there are no interactions with the base protocol that cause the standardised element of Diameter to fail, THAT is the essence of a vendor-specific extension. Fundamentally, I don't believe anyone will ever take the 'Private' path of registering a vendor's own extension with IANA if the 'whatever they wish' path is open. By definition an extension is something that adds to Diameter's functionality with out affecting the base protocol. If it has interaction swith the base protocol, then it is surely an 'enhancement', and in that case it has to be standardised, or it has to be recognised as something other than Diameter. Dan ------_=_NextPart_001_01C2122A.800DD7F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor = extens ions

> a vendor may do whatever they wish.  the = point is what they can do and
> still call it diameter.  when they call it = diameter, the customer has
> a legitimate expectiation that vendor A's = diameter will inter-operate
> with vendor B's diameter.  that is what = standards are all about.

From what you say here, it sounds to me that we = actually have three cases rather than the two that John = described.  There is the Public, IETF standardised extensions and = 'Private', vendor extensions, and then there is this third 'a vendor = may do whatever they wish' extension, just so long as they don't call = it Diameter.

My continued confusion is that if you accept that 'a = vendor may do whatever they wish', and whatever they wish is defined in = a way that says 'if you don't understand it, ignore it' and there are = no interactions with the base protocol that cause the standardised = element of Diameter to fail, THAT is the essence of a vendor-specific = extension.  Fundamentally, I don't believe anyone will ever take = the 'Private' path of registering a vendor's own extension with IANA if = the 'whatever they wish' path is open.  By definition an extension = is something that adds to Diameter's functionality with out affecting = the base protocol.  If it has interaction swith the base protocol, = then it is surely an 'enhancement', and in that case it has to be = standardised, or it has to be recognised as something other than = Diameter.

Dan

------_=_NextPart_001_01C2122A.800DD7F4-- From owner-aaa-wg@merit.edu Wed Jun 12 12:05: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 MAA03008 for ; Wed, 12 Jun 2002 12:05:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C3DD912F9; Wed, 12 Jun 2002 12:06:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31729912FD; Wed, 12 Jun 2002 12:06: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 1B963912F9 for ; Wed, 12 Jun 2002 12:06:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5674D5DE34; Wed, 12 Jun 2002 12:05:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 8E0145DDB7 for ; Wed, 12 Jun 2002 12:05:58 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CG5pD14324; Wed, 12 Jun 2002 18:05:51 +0200 (MEST) 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 g5CG5nQ13999; Wed, 12 Jun 2002 17:05:50 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 17:05:49 +0100 Message-ID: From: "Daniel Warren" To: "'john.loughney@nokia.com'" , randy@psg.com Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions Date: Wed, 12 Jun 2002 17:05:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2122B.0469E45C" 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_01C2122B.0469E45C Content-Type: text/plain; charset="iso-8859-1" John 'In the case when a vendor extensions is marked as mandatory, any failures MUST be the fault of the sending side (the side which sends extension marked as mandatory). Also, the system MUST be able to work without the non-standard extension.' This text makes no sense. If the system can work without a non-standard extension then the extension is not Mandatory, it's Optional. In short, there cannot be a mandatory non-standard extension to anything, it HAS to be optional, otherwise it HAS to be standardised. Dan -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: 12 June 2002 16:59 To: randy@psg.com; Warren, Daniel [MDN05:EP10:EXCH] Cc: aaa-wg@merit.edu; mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Hi Randy, > a vendor may do whatever they wish. the point is what they can do and > still call it diameter. when they call it diameter, the customer has > a legitimate expectiation that vendor A's diameter will inter-operate > with vendor B's diameter. that is what standards are all about. I agree. I propose the following for vendor extensions: We need a way for vendors to 'register' their extensions, so that there is some paper trail. In the case when a vendor extensions is marked as mandatory, any failures MUST be the fault of the sending side (the side which sends extension marked as mandatory). Also, the system MUST be able to work without the non-standard extension. In summary, all vendor extensions MUST NOT harm interoperability. I propose to add this kind of text to 1.2 'Approach to Extensibility' and to make the text in the IANA section more bullet-proof. Also, a recommendation that vendors submit documentation for consideration as Informational RFCs may be a good recommendation as well. John ------_=_NextPart_001_01C2122B.0469E45C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor = extensions

John

'In the case when a vendor extensions is marked as = mandatory, any failures
MUST be the fault of the sending side (the side = which sends extension marked
as mandatory).  Also, the system MUST be able = to work without the
non-standard extension.'

This text makes no sense.  If the system can = work without a non-standard extension then the extension is not = Mandatory, it's Optional.  In short, there cannot be a mandatory = non-standard extension to anything, it HAS to be optional, otherwise it = HAS to be standardised.

Dan

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: 12 June 2002 16:59
To: randy@psg.com; Warren, Daniel = [MDN05:EP10:EXCH]
Cc: aaa-wg@merit.edu; mankin@isi.edu
Subject: RE: [AAA-WG]: Diameter IETF Standard = extensions vs. Vendor
extensions


Hi Randy,


> a vendor may do whatever they wish.  the = point is what they can do and
> still call it diameter.  when they call it = diameter, the customer has
> a legitimate expectiation that vendor A's = diameter will inter-operate
> with vendor B's diameter.  that is what = standards are all about.

I agree.  I propose the following for vendor = extensions:

We need a way for vendors to 'register' their = extensions, so that there
is some paper trail. 

In the case when a vendor extensions is marked as = mandatory, any failures
MUST be the fault of the sending side (the side = which sends extension marked
as mandatory).  Also, the system MUST be able = to work without the
non-standard extension.  In summary, all vendor = extensions MUST NOT
harm interoperability.

I propose to add this kind of text to 1.2 'Approach = to Extensibility' and
to make the text in the IANA section more = bullet-proof.  Also, a recommendation
that vendors submit documentation for consideration = as Informational RFCs may
be a good recommendation as well.

John

------_=_NextPart_001_01C2122B.0469E45C-- From owner-aaa-wg@merit.edu Wed Jun 12 12:16: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 MAA03353 for ; Wed, 12 Jun 2002 12:16:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E523591300; Wed, 12 Jun 2002 12:15:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFAE091303; Wed, 12 Jun 2002 12:15: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 5FB9A91300 for ; Wed, 12 Jun 2002 12:15:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 947D05DE46; Wed, 12 Jun 2002 12:15: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 E763F5DE44 for ; Wed, 12 Jun 2002 12:15:43 -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 g5CGGIi25727 for ; Wed, 12 Jun 2002 19:16:18 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Jun 2002 19:15:52 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 12 Jun 2002 19:15:51 +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 IETF Standard extensions vs. Vendor extensions Date: Wed, 12 Jun 2002 19:15:51 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65421@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Thread-Index: AcISKx1nnIi0CmzRQICNyZBRoFBZXgAAKQzA From: To: , Cc: , X-OriginalArrivalTime: 12 Jun 2002 16:15:51.0786 (UTC) FILETIME=[6BE584A0:01C2122C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03353 Dan, 'In the case when a vendor extensions is marked as mandatory, any failures MUST be the fault of the sending side (the side which sends extension marked as mandatory). Also, the system MUST be able to work without the non-standard extension.' > This text makes no sense. If the system can work without a non-standard > extension then the extension is not Mandatory, it's Optional. In short, > there cannot be a mandatory non-standard extension to anything, it HAS > to be optional, otherwise it HAS to be standardised. It is possible in the base spec to set vendor AVPs to be mandatory. This is not a problem, it is based upon experiences with Radius. What is needed is to sort out the rules for this and ensure the correct paper trail. John From owner-aaa-wg@merit.edu Wed Jun 12 12:16:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03394 for ; Wed, 12 Jun 2002 12:16:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6107C91303; Wed, 12 Jun 2002 12:16:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3234491304; Wed, 12 Jun 2002 12:16: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 D41C991303 for ; Wed, 12 Jun 2002 12:16:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9904F5DE46; Wed, 12 Jun 2002 12:16:46 -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 77C845DE44 for ; Wed, 12 Jun 2002 12:16:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17IAnl-000EYC-00; Wed, 12 Jun 2002 09:16:54 -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]: Diameter IETF Standard extensions vs. Vendor extensions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6541D@esebe004.NOE.Nokia.com> Message-Id: Date: Wed, 12 Jun 2002 09:16:54 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> a vendor may do whatever they wish. the point is what they can do and >> still call it diameter. when they call it diameter, the customer has >> a legitimate expectiation that vendor A's diameter will inter-operate >> with vendor B's diameter. that is what standards are all about. > > I agree. I propose the following for vendor extensions: > > We need a way for vendors to 'register' their extensions, so that there > is some paper trail. > > In the case when a vendor extensions is marked as mandatory, any failures > MUST be the fault of the sending side (the side which sends extension > marked as mandatory). Also, the system MUST be able to work without the > non-standard extension. In summary, all vendor extensions MUST NOT harm > interoperability. > > I propose to add this kind of text to 1.2 'Approach to Extensibility' and > to make the text in the IANA section more bullet-proof. Also, a > recommendation that vendors submit documentation for consideration as > Informational RFCs may be a good recommendation as well. makes sense to me. or at least i don't think i will have this immediately splatted in my face if i pass it to the iesg. randy From owner-aaa-wg@merit.edu Wed Jun 12 12:18: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 MAA03427 for ; Wed, 12 Jun 2002 12:18:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E00291304; Wed, 12 Jun 2002 12:18:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 212D791305; Wed, 12 Jun 2002 12:18:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21E3391304 for ; Wed, 12 Jun 2002 12:18:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 612915DE47; Wed, 12 Jun 2002 12:18:17 -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 CF5E55DE44 for ; Wed, 12 Jun 2002 12:18:16 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020612161824.KSBY15064.fep02-svc.swip.net@ipunplugged.com> for ; Wed, 12 Jun 2002 18:18:24 +0200 Message-ID: <3D0790EE.5060501@ipunplugged.com> Date: Wed, 12 Jun 2002 18:20:30 +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: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue References: <07A6D72550C5E0459DE676439EE53846E32B83@esebe012.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 My assessment of the situation is identical to Mikko's. I would find it highly enlightening if someone were to point out how the current drafts allow an extension that interacts with the IETF Diameter protocol. Until this is done I am of the opinion that we are chasing a problem that does not exist. *Unless* what Randy really means is that the vendor would try to pass the extension itself off as Diameter. An implementation that understands a private vendor-specific application but behaves according to all relevant IETF Diameter documents is and should be a conforming Diameter implementation in my book. j mikko.aittola@nokia.com wrote: >Hello, > >Vendor-specific extensions to Diameter are not meant to modify a standard. >The intention is that vendor-specific extensions use and support fully >IETF-standard Diameter Base Protocol. The vendor-specific extensions do not >modify anything that is defined in Diameter Base Protocol standard. > >The current Base Protocol draft specifies a standard way to make the extensions. >It also defines means that ensure that the communicating entities know what >extensions, if any, are supported at a given time. > >As I have understand it, the requirement for the extensibility is also >defined in RFC 2989, Criteria for Evaluating AAA Protocols for Network Access. > >I'm a bit afraid that if it is not allowed to standardize how to make >vendor-specific extensions, the vendors will make the extensions in >ad-hoc ways -- causing interoperability problems galore. > > >Best Regards, >Mikko > > > From owner-aaa-wg@merit.edu Wed Jun 12 12:44: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 MAA04321 for ; Wed, 12 Jun 2002 12:44:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38255912CC; Wed, 12 Jun 2002 12:44:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0787C91305; Wed, 12 Jun 2002 12:44: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 05F3B912CC for ; Wed, 12 Jun 2002 12:44:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 078035DE49; Wed, 12 Jun 2002 12:44:51 -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 A8FF85DE44 for ; Wed, 12 Jun 2002 12:44:50 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user260.cisco.com [10.70.83.4]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA05891; Wed, 12 Jun 2002 09:44:50 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Randy Bush" , "Daniel Warren" Cc: , , Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Date: Wed, 12 Jun 2002 09:44:48 -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) Importance: Normal In-Reply-To: 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: ... > > a vendor may do whatever they wish. the point is what they can do and > still call it diameter. when they call it diameter, the customer has > a legitimate expectiation that vendor A's diameter will inter-operate > with vendor B's diameter. So you are saying that a customer's expectation that vendor A's _vendor-specific extensions_ to Diameter will be supported by any, arbitrary vendor B is legitimate? > that is what standards are all about. > > randy > > > From owner-aaa-wg@merit.edu Wed Jun 12 12: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 MAA04627 for ; Wed, 12 Jun 2002 12:54:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B95791305; Wed, 12 Jun 2002 12:55:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAC0D91306; Wed, 12 Jun 2002 12:55: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 D979991305 for ; Wed, 12 Jun 2002 12:55:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2184C5DE49; Wed, 12 Jun 2002 12:54:57 -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 C72ED5DE44 for ; Wed, 12 Jun 2002 12:54:56 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user260.cisco.com [10.70.83.4]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA21842; Wed, 12 Jun 2002 09:54:56 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , , Cc: , Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Date: Wed, 12 Jun 2002 09:54:53 -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) Importance: Normal In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6541D@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > Hi Randy, > > > > a vendor may do whatever they wish. the point is what they can do and > > still call it diameter. when they call it diameter, the customer has > > a legitimate expectiation that vendor A's diameter will inter-operate > > with vendor B's diameter. that is what standards are all about. > > I agree. I propose the following for vendor extensions: > > We need a way for vendors to 'register' their extensions, so that there > is some paper trail. > > In the case when a vendor extensions is marked as mandatory, any failures > MUST be the fault of the sending side (the side which sends > extension marked > as mandatory). Also, the system MUST be able to work without the > non-standard extension. Please define the term "work". > In summary, all vendor extensions MUST NOT > harm interoperability. > > I propose to add this kind of text to 1.2 'Approach to Extensibility' and > to make the text in the IANA section more bullet-proof. Also, a > recommendation > that vendors submit documentation for consideration as > Informational RFCs may > be a good recommendation as well. > > John > > From owner-aaa-wg@merit.edu Wed Jun 12 13:42: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 NAA06445 for ; Wed, 12 Jun 2002 13:42:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17941912CE; Wed, 12 Jun 2002 13:42:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7038912CF; Wed, 12 Jun 2002 13:42:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3F39912CE for ; Wed, 12 Jun 2002 13:42:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32E655DE4D; Wed, 12 Jun 2002 13:42:16 -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 A8E725DE44 for ; Wed, 12 Jun 2002 13:42:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5CGqaq26307; Wed, 12 Jun 2002 09:52:36 -0700 Date: Wed, 12 Jun 2002 09:52:36 -0700 (PDT) From: Bernard Aboba To: Randy Bush Cc: john.loughney@nokia.com, , , Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > In the case when a vendor extensions is marked as mandatory, any failures > > MUST be the fault of the sending side (the side which sends extension > > marked as mandatory). We already have this language for Vendor-Specific AVPs. But there is no 'M bit' for Vendor-Specific commands. I'm not even clear this would make sense, except perhaps for accounting, where a non-mandatory VSC could be interpretted as an ordinary ACR/ACA if the accounting server did not support it. However, it could be argued that the same effect could be obtained by just using ACR/ACA and adding some vendor-specific AVPs, so this probably isn't worthwhile. > > Also, the system MUST be able to work without the > > non-standard extension. In summary, all vendor extensions MUST NOT harm > > interoperability. Some Vendor-Specific AVPs are by their nature mandatory: for example, anything relating to security. In RADIUS, a NAS can discard a vendor-specific Filter attribute and deliver a different service than what the RADIUS server requested without even sending an error message. But in Diameter we are attempting to do better than that, so such an AVP would be Vendor-Specific and carry the 'M' bit. That is a good thing, because if the NAS doesn't implement the AVP, it's preferrable for the session not to come up, and an error message to result, so the admin can debug it. For similar reasons, I'm not sure what 'work' means in the context of a Vendor-Specific Command (VSC). A VSC is only needed in cases where a standard command with vendor-specific AVPs won't do the job. So if it were possible to just add some AVPs to the Diameter Server dictionary, presumably you wouldn't be using a VSC in the first place. That suggests that a VSC by its nature implies code changes on both the NAS and Diameter server. If a NAS or Diameter server receives a VSC and doesn't have the code to implement it, there really is no way to 'work', except to avoid sending those VSCs in future. From owner-aaa-wg@merit.edu Thu Jun 13 00:06: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 AAA21684 for ; Thu, 13 Jun 2002 00:06:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1E77912E9; Thu, 13 Jun 2002 00:06:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64FD89130E; Thu, 13 Jun 2002 00:06: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 65D89912E9 for ; Thu, 13 Jun 2002 00:06:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B5F025DDD7; Thu, 13 Jun 2002 00:06:35 -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 13C945DDA4 for ; Thu, 13 Jun 2002 00:06:35 -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 g5D45Od05888 for ; Thu, 13 Jun 2002 07:05:24 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Jun 2002 07:06:43 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 13 Jun 2002 07:06: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]: Diameter IETF Standard extensions vs. Vendor extensions Date: Thu, 13 Jun 2002 07:06:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6542D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Thread-Index: AcISMecW1QJetitQT8yYrODmObVr3wAXVz7w From: To: , , Cc: , X-OriginalArrivalTime: 13 Jun 2002 04:06:43.0142 (UTC) FILETIME=[BA15F660:01C2128F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA21684 HI Glen, > Please define the term "work". Continue operation - i.e. - not crash, and preferably not abort. Basically, try to have fall back operation. I think the scenario would be that I am roaming and trying to be authenticated, if the visited network implenents a vendor extension which prevents communication to my home network because my home network does not implement the vendor extension, then this is a bad thing. John From owner-aaa-wg@merit.edu Thu Jun 13 01:29: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 BAA22970 for ; Thu, 13 Jun 2002 01:29:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 128C39130E; Thu, 13 Jun 2002 01:29:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7D5D9130F; Thu, 13 Jun 2002 01:29: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 ECDA09130E for ; Thu, 13 Jun 2002 01:29:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B78C5DE68; Thu, 13 Jun 2002 01:29:05 -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 9A4B25DDCF for ; Thu, 13 Jun 2002 01:29:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5D4dTk00780; Wed, 12 Jun 2002 21:39:29 -0700 Date: Wed, 12 Jun 2002 21:39:29 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu, Subject: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Issue In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6542D@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 > I think the scenario would be that I am roaming and trying to be authenticated, > if the visited network implenents a vendor extension which prevents communication > to my home network because my home network does not implement the vendor > extension, then this is a bad thing. I think that it is not very hard to go through the possible cases here, identify the potential interoperability problems with Vendor-Specific Commands, and fix them. An analysis follows. The first important thing to understand (which should already be clear from the spec), is that VSCs MUST NOT be used were an existing command and vendor-specific AVPs would do the job. If this basic precept is followed, then many of the possible interoperability problems evaporate and the analysis becomes relatively simply. If this premise can be accepted, then presumably the vendor specific command is used to provide a fundamentally different service from existing Diameter applications. Otherwise, an existing application would be used with vendor-specific AVPs, which could be mandatory or non-mandatory. For example, addition of vendor-specific AVPs to the existing ACR/ACA commands does not require a vendor-specific command. However, if you wanted to authenticate the Frobnitz service, which requires Frobnitz authentication and authorization AVPs, AS WELL AS NEW CODE ON THE AAA SERVER, then a new command MAY be appropriate. "NEW CODE" is in upper case because in my mind this is what differentiates VSCs from vendor-specific AVPs. Given this basic understanding of when VSCs are needed, there are two major cases to analyze: 1. VSC sent from NAS to AAA server. 2. VSC sent from AAA server to NAS. Case 1: VSC sent from NAS to AAA server. If the NAS then sends a vendor-specific Frobnitz command to the AAA server, and Frobnitz is fundamentally different service, several outcomes are possible: a. The AAA server supports Frobnitz, but the user isn't authorized for Frobnitz. b. The AAA server doesn't support Frobnitz. c. The AAA server supports Frobnitz, and the user is authorized for it. In case a, the server will respond to the Frobnitz command, but the user will not be authorized. In case b, the command won't be recognized, and as a result, the user will not be allowed to access the Frobnitz service. From the user perspective, the result is indistinguishable from case a, but from the NAS perspective the difference is between receiving a Reject and receiving an Error Message. In case c, the user may gain access to the Frobnitz service, depending on the outcome of the authentication. Assuming that Frobnitz is really a new application, not just an existing application adorned with a VSC, then I'd claim that there is no interoperability problem in outcomes a-c. It would make little difference if instead of a VSC, the NAS sent an existing command with a NAS-Port-Type=Frobnitz. If the AAA server doesn't understand what Frobnitz is, it probably shouldn't be blindly authorizing access to it. Most AAA servers I've seen are set up with policies that vary for bu NAS-Port-Type (e.g. different for PPP, VPN, 802.11, Mobile IPv4, etc.), so as to reject services that the home server isn't explicitly set up for. Case 2: VSC sent from AAA server to NAS. There are several cases here: a. NAS sends a standard command to AAA server, which responds with the Frobnitz VSC. b. AAA server sends an unsolicited Frobnitz command to the NAS. c. NAS sends a Frobnitz Request to the AAA server, which responds with a Frobnitz Answer. I'd claim that case a) is a legitimate interoperability problem and should be prohibited. That would require language saying "In response to an ACR, the AAA server MUST send an ACA..." I'd suggest we make sure that we have this language for all standard Diameter commands. Case b) is only an interoperability issue if the NAS were to change user state as a result of not understanding the Frobnitz command. If the NAS can silently discard Frobnitz without change of state, then this is effectively a "non-mandatory VSC" and there is no interoperability problem. I'd suggest that we add some language about processing unsolicited VSCs. Case c) is not an interoperability issue, since both peers support Frobnitz. Based on this analysis, it would seem to me that the issue can be resolved with a few small changes: a. Language to make it crystal clear that VSCs MUST NOT be sent in response to standard commands. b. Language to make it crystal clear that unsolicited VSCs sent from AAA server to NAS are to be treated as non-mandatory. c. Language to make it clear that VSCs MUST NOT be used when vendor-specific AVPs could be added to standard commands instead, achieving the same objective. From owner-aaa-wg@merit.edu Thu Jun 13 03:31:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03729 for ; Thu, 13 Jun 2002 03:31:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34E63912EA; Thu, 13 Jun 2002 03:30:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC5CE912EB; Thu, 13 Jun 2002 03:30:30 -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 34E97912EA for ; Thu, 13 Jun 2002 03:30:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6F7B5DE5F; Thu, 13 Jun 2002 03:30: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 D66F95DDC3 for ; Thu, 13 Jun 2002 03:30:13 -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 g5D7Uii09516 for ; Thu, 13 Jun 2002 10:30:44 +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 ; Thu, 13 Jun 2002 10:30:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 13 Jun 2002 10:30:18 +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]: Base Updated section 1.2 Date: Thu, 13 Jun 2002 10:30:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E57@esebe004.NOE.Nokia.com> Thread-Topic: Base Updated section 1.2 Thread-Index: AcISrCqO8c8aIOygQumgWgDwoiJTPQ== From: To: X-OriginalArrivalTime: 13 Jun 2002 07:30:18.0298 (UTC) FILETIME=[2AE2D9A0:01C212AC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA03729 Hi all, In order to resolve the current discussion, I have updated section 1.2. Most all of the information exists already in the Diameter document, in other sections, I have simply condensed it into the introduction for clarity's sake. Specific recomendation on text is welcome. John 1.2 Approach to Extensibility The Diameter protocol is designed to be extensible. The extensibility includes: - Defining new AVP values. - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures Reuse of existing AVP values, AVPs, applications and command codes are is strongly recommended. Reuse simplifies standardization effort, implentation effort and avoids potential interoperability issues. 1.2.1 Standardized Extensions Versus Vendor-Specific Extensions Diameter can be extended by standards track documents in the IETF. The benefit of this is that the extensions become Internet standards, allowing for wider possible deployment and higher assurance of interoperability. It is strongly recommended that extensions to Diameter be made by standards-track RFCs. Vendor-specific extensions are allowed, and MUST be registered through IANA (see section 11.2). However, vendor-specific extensions MUST NOT harm interoperability of standards-based Diameter implementations. Vendor-specific commands MUST NOT be used where an existing command plus a vendor-specific AVPs would the same objective. If this basic precept is followed, then most interoperability problems are solved. Vendor-specific commands MUST NOT be sent in response to standard commands. Unsolicited VSCs sent from a AAA server to a NAS are to be treated as non-mandatory. All vendor-specific Diameter commands require Informational RFCs documenting the command unless for Private Use as described in Section 11.2.1. As a general rule, any errors involving Vendor-specific AVP marked with the 'M' bit are considered the fault of the side setting the 'M' bit (see Section 4.1). 1.2.2 Defining New AVP Values New applications should attempt to reuse AVPs defined in existing applications when possible, as opposed to creating new AVPs. For AVPs of type Enumerated, it is possible the application requires a new value to communicate some service-specific information. In order to allocate a new AVP value, a request MUST be sent to IANA [IANA], with a detailed explanation of the value and document on the value. 1.2.3 Creating New AVPs When no existing AVP can be used appropriately to communicate some service-specific information, a new AVP should be created. The new AVP being defined MUST follow one of the types listed in section 4.3. In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is highly recommended that a Grouped AVP be used (see Section 4.5). In order to create a new AVP, a request MUST be sent to IANA, with a detailed explanation of the AVP, its type and possible values. Furthermore, the request MUST include the commands that would make use of the AVP. 1.2.4 Creating New Authentication Applications Should a new application require Diameter support, but it cannot fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include: - Requiring a whole different set of mandatory AVPs to a command - Requiring a command that has a different number of round trips to satisfy a request (e.g. application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete). - The method used to authenticate the user is drastically different from any existing application, and the authentication information cannot be carried within the AVPs defined in the application. Note that the creation of a new application should be viewed as a last resort. New Diameter applications MUST define at least one Command Code, the expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY also define new AVPs. If the Diameter application has any accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see section 9.3). When possible, a new Diameter application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter application specification MUST have an IANA assigned Application Identifier (see section 2.4). 1.2.5 Creating New Accounting Applications Services that have an Application Identifier MUST use the same identifier also to identify the service when Diameter accounting is used. There are services that only require the use of Diameter accounting. Such services need to define the service specific AVPs that must be carried in the Accounting-Request/Answer messages, but do not need to define command codes. Application Identifiers are, however, still required for accounting due to the Diameter capability discovery process. Every accounting application MUST have either an IANA allocated Application Identifier, or a vendor specific Application Identifier. Note that the creation of a new application should be viewed as a last resort and should be used only when Vendor-Specific AVPs are insufficient. In most cases, reusing an existing Application ID with Vendor-Specific AVPs should work. For example, many accounting servers are set up to write AVPs to disk, so they can handle even mandatory vendor-specific AVPs that they don't understand. This is why "disk writing" accounting servers should advertise themselves as "Relays" that can handle any Application ID, including Vendor-Specific. When possible, a new Diameter accounting application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter accounting application specification MUST have an IANA assigned Application Identifier (see section 2.4). 1.2.6 Application Authentication Procedures When possible, applications SHOULD be designed such that new authentication methods MAY be added without requiring changes to the application. This MAY require that new AVP values be assigned to represent the new authentication transform, or any other scheme that produces similar results. When possible, authentication frameworks, such as Extensible Authentication Protocol [EAP], SHOULD be used. From owner-aaa-wg@merit.edu Thu Jun 13 04:37:01 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 EAA04829 for ; Thu, 13 Jun 2002 04:37:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80F0691318; Thu, 13 Jun 2002 04:34:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 328AE91319; Thu, 13 Jun 2002 04:34:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4A5291314 for ; Thu, 13 Jun 2002 04:34:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 314995DE5D; Thu, 13 Jun 2002 04:34:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id DA6A55DDB6 for ; Thu, 13 Jun 2002 04:34:14 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26278; Thu, 13 Jun 2002 01:34:22 -0700 (PDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5D8YKb25116; Thu, 13 Jun 2002 10:34:20 +0200 (MEST) Date: Thu, 13 Jun 2002 01:34:13 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Base Updated section 1.2 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E57@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 John, On Thu, 13 Jun 2002 john.loughney@nokia.com wrote: > Specific recomendation on text is welcome. Here goes. > 1.2 Approach to Extensibility > > The Diameter protocol is designed to be extensible. The extensibility > includes: > > - Defining new AVP values. > - Creating new AVPs > - Creating new authentication/authorization applications > - Creating new accounting applications > - Application authentication procedures > > Reuse of existing AVP values, AVPs, applications and command codes are > is strongly recommended. Reuse simplifies standardization effort, > implentation effort and avoids potential interoperability issues. The following text made it possible to get RFC 3224, Vendor Extensions to SLP, through. There were concerns that the document could be read as *encouraging* vendor extension. From Abstract: While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. From Introduction: Vendor extensions to standard protocols come at a cost. - Vendor extensions occur without review from the community. They may not make good engineering sense in the context of the protocol they extend, and the engineers responsible may discover this too late. - Vendor extensions preclude interoperation with compliant but non-extended implementations. There is a real danger of incompatibility if different implementations support different feature sets. - By extending SLPv2 privately, ubiquitous automatic configuration is impossible, which is the primary benefit of a standard service discovery framework. By spelling out the disadvantages to readers, it is possible to put vendor extensibility in an appropriate light. This doesn't solve the IESG's issues, but it ameliorates them. > 1.2.1 Standardized Extensions Versus Vendor-Specific Extensions > > Diameter can be extended by standards track documents in the IETF. > The benefit of this is that the extensions become Internet standards, > allowing for wider possible deployment and higher assurance of > interoperability. It is strongly recommended that extensions to > Diameter be made by standards-track RFCs. > > Vendor-specific extensions are allowed, and MUST be registered through > IANA (see section 11.2). However, vendor-specific extensions MUST NOT > harm interoperability of standards-based Diameter implementations. > > Vendor-specific commands MUST NOT be used where an existing command plus a > vendor-specific AVPs would the same objective. If this basic precept is > followed, then most interoperability problems are solved. Vendor-specific > commands MUST NOT be sent in response to standard commands. Unsolicited VSCs > sent from a AAA server to a NAS are to be treated as non-mandatory. All > vendor-specific Diameter commands require Informational RFCs documenting > the command unless for Private Use as described in Section 11.2.1. > > As a general rule, any errors involving Vendor-specific AVP marked with > the 'M' bit are considered the fault of the side setting the 'M' bit (see > Section 4.1). > > 1.2.2 Defining New AVP Values > > New applications should attempt to reuse AVPs defined in existing > applications when possible, as opposed to creating new AVPs. For AVPs > of type Enumerated, it is possible the application requires a new > value to communicate some service-specific information. > > In order to allocate a new AVP value, a request MUST be sent to IANA > [IANA], with a detailed explanation of the value and document on the > value. This technique puts an onerous burden on IANA. Current practice is for the IESG to appoint a 'designated expert' on Diameter extensibility. All requests for IANA registration of extensions get funneled through him or her. The designated expert must review the clarity and completeness of the specification, and if needed, seek additional technical review from the community. If there is a dispute, one can use the standard IETF appeals process to challenge the authority of the Designated Expert. The rules for this are set forth in RFC 2434, under the Designated Expert policy. Example text using RFC 2434 policy is in RFC 2608 (SLPv2): New SLP Extensions with types in the range 2-65535 may be registered following review by a Designated Expert. This means the process is as follows: a) a group wants to register an extension. They prepare a specification and post it publicly for download. b) the group contacts the designated expert. This can be done by specifying a well known email alias (diameter-extension@iana.org) that the designated expert monitors c) the designated expert reviews the doc on a best effort basis and works with the authors and community to ensure the doc is reasonably clear and complete, not redundent and not harmful. d) once the doc is in reasonable shape, the Designated Expert passes a version of the text to add to an IANA registry page. For example, "Please add CODE=0x9234 NAME=blahblah AUTHOR CONTACT=a@b SPECIFICATION=http://example.org/spec.txt to AVP extension table of the Diameter Extensions page." This process can be very swift for simple extensions. If there is an active community of implementors and users, as there will be for Diameter, one can vet new suggestions on a mailing list, with the authority and discretion still being in the hands of the Designated Expert. > 1.2.3 Creating New AVPs > > When no existing AVP can be used appropriately to communicate some > service-specific information, a new AVP should be created. The new > AVP being defined MUST follow one of the types listed in section 4.3. > In the event that a logical grouping of AVPs is necessary, and > multiple "groups" are possible in a given command, it is highly > recommended that a Grouped AVP be used (see Section 4.5). > > In order to create a new AVP, a request MUST be sent to IANA, with a > detailed explanation of the AVP, its type and possible values. > Furthermore, the request MUST include the commands that would make > use of the AVP. Please see RFC 3080, The Blocks Extensible Exchange Protocol Core, Section 5, for an excellent set of sections for describing process for defining new extensions. What we should have in the 1.2 subsections is a set of templates to fill in - to send to the designated expert. These templates could be filed with IANA as part of registration, after the kinks get worked out of them. The templates are not a replacement for a spec. Example of one: RFC 3080, 5.1 Profile Registration Template When a profile is registered, the following information is supplied: Profile Identification: specify a URI [10] that authoritatively identifies this profile. Message Exchanged during Channel Creation: specify the datatypes that may be exchanged during channel creation. Messages starting one-to-one exchanges: specify the datatypes that may be present when an exchange starts. Messages in positive replies: specify the datatypes that may be present in a positive reply. Messages in negative replies: specify the datatypes that may be present in a negative reply. Messages in one-to-many exchanges: specify the datatypes that may be present in a one-to-many exchange. Message Syntax: specify the syntax of the datatypes exchanged by the profile. Message Semantics: specify the semantics of the datatypes exchanged by the profile. Contact Information: specify the postal and electronic contact information for the author of the profile. The template for the section 1.2.3 could be: When a new AVP is registered, the following information is supplied: What Application is the AVP intended to be used in? What Commands make use of the AVP? What is the AVP's type? What are its possible values and how can one interpret these values? Are there any restrictions on use of the AVP? For example are there any additional AVPs which are needed to intepret the AVP correctly? Are there any AVPs which cannot appear in the same command as this AVP (or it won't make sense, etc)? Does this AVP change the interpretation of any other AVP or command? What are the side effects of including this AVP in a command? When is appropriate to set the Mandatory 'M' bit in the AVP? How is the AVP used? Where is the specification for the AVP? What is the contact information for further questions. Please include postal and electronic contact information for the author of the AVP extension. Erik From owner-aaa-wg@merit.edu Thu Jun 13 04:56: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 EAA05057 for ; Thu, 13 Jun 2002 04:56:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A7D4912EC; Thu, 13 Jun 2002 04:56:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2ADB91314; Thu, 13 Jun 2002 04:56: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 8969E912EC for ; Thu, 13 Jun 2002 04:56:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB8CF5DE5F; Thu, 13 Jun 2002 04:56:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 7AECE5DE5D for ; Thu, 13 Jun 2002 04:56:53 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00431; Thu, 13 Jun 2002 02:57:02 -0600 (MDT) Received: from ntg04 (ntg04 [129.157.142.144]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5D8uxb25837; Thu, 13 Jun 2002 10:56:59 +0200 (MEST) Date: Thu, 13 Jun 2002 01:56:51 -0700 (PDT) From: Erik Guttman X-Sender: erikg@ntg04 To: john.loughney@nokia.com Cc: Erik Guttman , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Base Updated section 1.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk John, One more suggestion - a propos to current discussion. If we add an additional question to the proposed 'AVP Registration Template' we put the burden of proof of uniqueness and need for the AVP into the requester's hands. Erik wrote: > The template for the section 1.2.3 could be: > > When a new AVP is registered, the following information is supplied: > Why are no existing standard AVPs suitable? If an existing AVP or combination of existing AVPs suffice, this AVP registration will be rejected. Erik From owner-aaa-wg@merit.edu Thu Jun 13 05:25: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 FAA05471 for ; Thu, 13 Jun 2002 05:25:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96F3291312; Thu, 13 Jun 2002 05:25:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6209A91313; Thu, 13 Jun 2002 05:25: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 5EA9291312 for ; Thu, 13 Jun 2002 05:25:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB85D5DE69; Thu, 13 Jun 2002 05:25:33 -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 510765DD9A for ; Thu, 13 Jun 2002 05:25:33 -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 g5D9PcmG011490; Thu, 13 Jun 2002 11:25:38 +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 MZT3LKT0; Thu, 13 Jun 2002 11:25:38 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 11:25:38 +0200 Message-ID: <577066326047D41180AC00508B955DDA06C4536A@eestqnt104> X-Sybari-Trust: e62d2154 2a03b045 ce6f5b63 00000138 From: "Carolina Canales Valenzuela (ECE)" To: "'Bernard Aboba'" , john.loughney@nokia.com Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue Date: Thu, 13 Jun 2002 11:21:39 +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, perhaps with all this discussion I've lost the point and I don't see something that is very obvious but...why should a NAS send a Vendor-specific command to a AAA server that doesn't understand it, or vice-versa? What do we have the whole CER/CEA mechanism for? (I thought this was used to reach an agreement about the applications that each peer understands, even if they are Vendor-specific)... Thank you! Carolina >-----Original Message----- >From: Bernard Aboba [mailto:aboba@internaut.com] >Sent: Thursday, June 13, 2002 6:39 AM >To: john.loughney@nokia.com >Cc: aaa-wg@merit.edu; mankin@isi.edu >Subject: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands >Issue > > >> I think the scenario would be that I am roaming and trying >to be authenticated, >> if the visited network implenents a vendor extension which >prevents communication >> to my home network because my home network does not >implement the vendor >> extension, then this is a bad thing. > >I think that it is not very hard to go through the possible cases here, >identify the potential interoperability problems with Vendor-Specific >Commands, and fix them. An analysis follows. > >The first important thing to understand (which should already be clear >from the spec), is that VSCs MUST NOT be used were an existing >command and >vendor-specific AVPs would do the job. If this basic precept >is followed, >then many of the possible interoperability problems evaporate and the >analysis becomes relatively simply. > >If this premise can be accepted, then presumably the vendor specific >command is used to provide a fundamentally different service from >existing Diameter applications. Otherwise, an existing application >would be used with vendor-specific AVPs, which could be >mandatory or non-mandatory. > >For example, addition of vendor-specific AVPs to the existing ACR/ACA >commands does not require a vendor-specific command. However, if you >wanted to authenticate the Frobnitz service, which requires Frobnitz >authentication and authorization AVPs, AS WELL AS NEW CODE ON THE AAA >SERVER, then a new command MAY be appropriate. "NEW CODE" is >in upper case >because in my mind this is what differentiates VSCs from >vendor-specific >AVPs. > >Given this basic understanding of when VSCs are needed, there are two >major cases to analyze: > >1. VSC sent from NAS to AAA server. >2. VSC sent from AAA server to NAS. > >Case 1: VSC sent from NAS to AAA server. > >If the NAS then sends a vendor-specific Frobnitz command to the AAA >server, and Frobnitz is fundamentally different service, >several outcomes >are possible: > >a. The AAA server supports Frobnitz, but the user isn't authorized for >Frobnitz. > >b. The AAA server doesn't support Frobnitz. > >c. The AAA server supports Frobnitz, and the user is authorized for it. > >In case a, the server will respond to the Frobnitz command, >but the user >will not be authorized. > >In case b, the command won't be recognized, and as a result, >the user will >not be allowed to access the Frobnitz service. From the user >perspective, >the result is indistinguishable from case a, but from the NAS >perspective >the difference is between receiving a Reject and receiving an Error >Message. > >In case c, the user may gain access to the Frobnitz service, >depending on >the outcome of the authentication. > >Assuming that Frobnitz is really a new application, not just >an existing >application adorned with a VSC, then I'd claim that there is no >interoperability problem in outcomes a-c. It would make little >difference >if instead of a VSC, the NAS sent an existing command with a >NAS-Port-Type=Frobnitz. > >If the AAA server doesn't understand what Frobnitz is, it >probably shouldn't be >blindly authorizing access to it. Most AAA servers I've seen are set up >with policies that vary for bu NAS-Port-Type (e.g. different >for PPP, VPN, >802.11, Mobile IPv4, etc.), so as to reject services that the >home server >isn't explicitly set up for. > >Case 2: VSC sent from AAA server to NAS. > >There are several cases here: > >a. NAS sends a standard command to AAA server, which responds with the >Frobnitz VSC. > >b. AAA server sends an unsolicited Frobnitz command to the NAS. > >c. NAS sends a Frobnitz Request to the AAA server, which >responds with a >Frobnitz Answer. > >I'd claim that case a) is a legitimate interoperability >problem and should >be prohibited. That would require language saying "In response >to an ACR, >the AAA server MUST send an ACA..." I'd suggest we make sure >that we have >this language for all standard Diameter commands. > >Case b) is only an interoperability issue if the NAS were to >change user >state as a result of not understanding the Frobnitz command. If the NAS >can silently discard Frobnitz without change of state, then this is >effectively a "non-mandatory VSC" and there is no interoperability >problem. I'd suggest that we add some language about processing >unsolicited VSCs. > >Case c) is not an interoperability issue, since both peers support >Frobnitz. > >Based on this analysis, it would seem to me that the issue can >be resolved >with a few small changes: > >a. Language to make it crystal clear that VSCs MUST NOT be sent in >response to standard commands. > >b. Language to make it crystal clear that unsolicited VSCs >sent from AAA >server to NAS are to be treated as non-mandatory. > >c. Language to make it clear that VSCs MUST NOT be used when >vendor-specific AVPs could be added to standard commands instead, >achieving the same objective. > From owner-aaa-wg@merit.edu Thu Jun 13 05:35:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05575 for ; Thu, 13 Jun 2002 05:35:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86D8A91313; Thu, 13 Jun 2002 05:35:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BC8B91314; Thu, 13 Jun 2002 05:35: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 4E90E91313 for ; Thu, 13 Jun 2002 05:35:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A1C585DE70; Thu, 13 Jun 2002 05:35:42 -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 3712A5DD9A for ; Thu, 13 Jun 2002 05:35:42 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5D9Zm6n003796; Thu, 13 Jun 2002 11:35:48 +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 M3JPDT0V; Thu, 13 Jun 2002 11:35:48 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 11:35:05 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED23BC@eestqnt104> X-Sybari-Trust: 7c3c6be9 2a03b045 174f49cf 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "Carolina Canales Valenzuela (ECE)" , "'Bernard Aboba'" , john.loughney@nokia.com Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue Date: Thu, 13 Jun 2002 11:31:14 +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 Exactly. Isn't the faulty case that a peer responds to a standard command with a VSC, identical to the faulty case where a peer responds to a standard command with a respond not corresponding to the request? VSCs are not different to any other standard command with respect to interoperability. BR/Miguel -----Original Message----- From: Carolina Canales Valenzuela (ECE) [mailto:carolina.canales-valenzuela@ece.ericsson.se] Sent: jueves, 13 de junio de 2002 11:22 To: 'Bernard Aboba'; john.loughney@nokia.com Cc: aaa-wg@merit.edu; mankin@isi.edu Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue Hi, perhaps with all this discussion I've lost the point and I don't see something that is very obvious but...why should a NAS send a Vendor-specific command to a AAA server that doesn't understand it, or vice-versa? What do we have the whole CER/CEA mechanism for? (I thought this was used to reach an agreement about the applications that each peer understands, even if they are Vendor-specific)... Thank you! Carolina >-----Original Message----- >From: Bernard Aboba [mailto:aboba@internaut.com] >Sent: Thursday, June 13, 2002 6:39 AM >To: john.loughney@nokia.com >Cc: aaa-wg@merit.edu; mankin@isi.edu >Subject: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands >Issue > > >> I think the scenario would be that I am roaming and trying >to be authenticated, >> if the visited network implenents a vendor extension which >prevents communication >> to my home network because my home network does not >implement the vendor >> extension, then this is a bad thing. > >I think that it is not very hard to go through the possible cases here, >identify the potential interoperability problems with Vendor-Specific >Commands, and fix them. An analysis follows. > >The first important thing to understand (which should already be clear >from the spec), is that VSCs MUST NOT be used were an existing >command and >vendor-specific AVPs would do the job. If this basic precept >is followed, >then many of the possible interoperability problems evaporate and the >analysis becomes relatively simply. > >If this premise can be accepted, then presumably the vendor specific >command is used to provide a fundamentally different service from >existing Diameter applications. Otherwise, an existing application >would be used with vendor-specific AVPs, which could be >mandatory or non-mandatory. > >For example, addition of vendor-specific AVPs to the existing ACR/ACA >commands does not require a vendor-specific command. However, if you >wanted to authenticate the Frobnitz service, which requires Frobnitz >authentication and authorization AVPs, AS WELL AS NEW CODE ON THE AAA >SERVER, then a new command MAY be appropriate. "NEW CODE" is >in upper case >because in my mind this is what differentiates VSCs from >vendor-specific >AVPs. > >Given this basic understanding of when VSCs are needed, there are two >major cases to analyze: > >1. VSC sent from NAS to AAA server. >2. VSC sent from AAA server to NAS. > >Case 1: VSC sent from NAS to AAA server. > >If the NAS then sends a vendor-specific Frobnitz command to the AAA >server, and Frobnitz is fundamentally different service, >several outcomes >are possible: > >a. The AAA server supports Frobnitz, but the user isn't authorized for >Frobnitz. > >b. The AAA server doesn't support Frobnitz. > >c. The AAA server supports Frobnitz, and the user is authorized for it. > >In case a, the server will respond to the Frobnitz command, >but the user >will not be authorized. > >In case b, the command won't be recognized, and as a result, >the user will >not be allowed to access the Frobnitz service. From the user >perspective, >the result is indistinguishable from case a, but from the NAS >perspective >the difference is between receiving a Reject and receiving an Error >Message. > >In case c, the user may gain access to the Frobnitz service, >depending on >the outcome of the authentication. > >Assuming that Frobnitz is really a new application, not just >an existing >application adorned with a VSC, then I'd claim that there is no >interoperability problem in outcomes a-c. It would make little >difference >if instead of a VSC, the NAS sent an existing command with a >NAS-Port-Type=Frobnitz. > >If the AAA server doesn't understand what Frobnitz is, it >probably shouldn't be >blindly authorizing access to it. Most AAA servers I've seen are set up >with policies that vary for bu NAS-Port-Type (e.g. different >for PPP, VPN, >802.11, Mobile IPv4, etc.), so as to reject services that the >home server >isn't explicitly set up for. > >Case 2: VSC sent from AAA server to NAS. > >There are several cases here: > >a. NAS sends a standard command to AAA server, which responds with the >Frobnitz VSC. > >b. AAA server sends an unsolicited Frobnitz command to the NAS. > >c. NAS sends a Frobnitz Request to the AAA server, which >responds with a >Frobnitz Answer. > >I'd claim that case a) is a legitimate interoperability >problem and should >be prohibited. That would require language saying "In response >to an ACR, >the AAA server MUST send an ACA..." I'd suggest we make sure >that we have >this language for all standard Diameter commands. > >Case b) is only an interoperability issue if the NAS were to >change user >state as a result of not understanding the Frobnitz command. If the NAS >can silently discard Frobnitz without change of state, then this is >effectively a "non-mandatory VSC" and there is no interoperability >problem. I'd suggest that we add some language about processing >unsolicited VSCs. > >Case c) is not an interoperability issue, since both peers support >Frobnitz. > >Based on this analysis, it would seem to me that the issue can >be resolved >with a few small changes: > >a. Language to make it crystal clear that VSCs MUST NOT be sent in >response to standard commands. > >b. Language to make it crystal clear that unsolicited VSCs >sent from AAA >server to NAS are to be treated as non-mandatory. > >c. Language to make it clear that VSCs MUST NOT be used when >vendor-specific AVPs could be added to standard commands instead, >achieving the same objective. > From owner-aaa-wg@merit.edu Thu Jun 13 07:04: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 HAA06923 for ; Thu, 13 Jun 2002 07:04:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77C3091315; Thu, 13 Jun 2002 07:04:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42CA691316; Thu, 13 Jun 2002 07: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 2D34891315 for ; Thu, 13 Jun 2002 07:04:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B4EE5DE55; Thu, 13 Jun 2002 07:04: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 3CEA85DE34 for ; Thu, 13 Jun 2002 07:04:06 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user18.cisco.com [10.70.82.18]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id EAA26941; Thu, 13 Jun 2002 04:04:01 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , , Cc: , Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Date: Thu, 13 Jun 2002 04:03:56 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6542D@esebe004.NOE.Nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ohn.loughney@nokia.com [mailto:john.loughney@nokia.com] writes: > HI Glen, > > > Please define the term "work". > > Continue operation - i.e. - not crash, and preferably not abort. > Basically, > try to have fall back operation. Isn't that behavior already defined in the document? > > I think the scenario would be that I am roaming and trying to be > authenticated, > if the visited network implenents a vendor extension which > prevents communication > to my home network because my home network does not implement the vendor > extension, then this is a bad thing. Maybe, maybe not: if for some reason the visted network needs the extension to operate correctly (not that I can think of such a circumstance, but it's hard to imagine your example, too), I would prefer denial of access to unexplained, bizarre behavior (crash failure is almost always preferable to Byzantine failure). > > John > > From owner-aaa-wg@merit.edu Thu Jun 13 08: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 IAA09032 for ; Thu, 13 Jun 2002 08:23:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 176A791316; Thu, 13 Jun 2002 08:23:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8ACA91317; Thu, 13 Jun 2002 08:23: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 B0C5291316 for ; Thu, 13 Jun 2002 08:23:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D9BE5DE34; Thu, 13 Jun 2002 08:23:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id E9F2F5DE61 for ; Thu, 13 Jun 2002 08:23:44 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DCNmM27221 for ; Thu, 13 Jun 2002 14:23:48 +0200 (MEST) 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 g5DCNke03215 for ; Thu, 13 Jun 2002 13:23:47 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 13:23:50 +0100 Message-ID: From: "Daniel Warren" To: aaa-wg@merit.edu Subject: [AAA-WG]: Mandatory Vendor-specific AVP's Date: Thu, 13 Jun 2002 13:23:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212D5.2B487CA0" 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_01C212D5.2B487CA0 Content-Type: text/plain; charset="iso-8859-1" All I would like to just make sure that there is some common understanding about when a Vendor can define an AVP as being mandatory and what this actually means. Case 1 - Extending an IETF defined command by adding a Vendor Specific AVP In this case, the AVP has to be optional. Setting the Mandatory AVP bit would mean that all implementations would have to support this AVP in the command and so that would no longer be vendor specific, but would rather be a requirement. Case 2 - Vendor defines a Vendor Specific Command Within this command, the vendor is able to set Mandatory AVP's. That would indicate that if the Command is supported on an implementation, the AVP has to be present. However, the command as a whole has to be optional so that it does not violate interoperability with other vendor's implementations. These two points seem obvious to me, but I think the discussions of the last few days have shown some confusion about what a vendor can and cannot reasonably define and implement in terms of extensions to Diameter. Fundamentally, the rule has to be that no peer is obliged to implement any vendor specific extension, be it an AVP, Command, or entire application. Dan ------_=_NextPart_001_01C212D5.2B487CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mandatory Vendor-specific AVP's

All

I would like to just make sure that there is some = common understanding about when a Vendor can define an AVP as being = mandatory and what this actually means.

Case 1 - Extending an IETF defined command by adding = a Vendor Specific AVP
In this case, the AVP has to be optional.  = Setting the Mandatory AVP bit would mean that all implementations would = have to support this AVP in the command and so that would no longer be = vendor specific, but would rather be a requirement.

Case 2 - Vendor defines a Vendor Specific = Command
Within this command, the vendor is able to set = Mandatory AVP's.  That would indicate that if the Command is = supported on an implementation, the AVP has to be present.  = However, the command as a whole has to be optional so that it does not = violate interoperability with other vendor's = implementations.

These two points seem obvious to me, but I think the = discussions of the last few days have shown some confusion about what a = vendor can and cannot reasonably define and implement in terms of = extensions to Diameter.  Fundamentally, the rule has to be that no = peer is obliged to implement any vendor specific extension, be it an = AVP, Command, or entire application.

Dan

------_=_NextPart_001_01C212D5.2B487CA0-- From owner-aaa-wg@merit.edu Thu Jun 13 08:28: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 IAA09268 for ; Thu, 13 Jun 2002 08:28:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0A31D91317; Thu, 13 Jun 2002 08:28:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C95D091319; Thu, 13 Jun 2002 08:28: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 B7D7591317 for ; Thu, 13 Jun 2002 08:28:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 214B75DE61; Thu, 13 Jun 2002 08:28:43 -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 7416C5DE34 for ; Thu, 13 Jun 2002 08:28:42 -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 g5DCRVd26651 for ; Thu, 13 Jun 2002 15:27:31 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Jun 2002 15:28:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 13 Jun 2002 15:28:50 +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 IETF Standard extensions vs. Vendor extensions Date: Thu, 13 Jun 2002 15:28:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65443@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Thread-Index: AcISyn+0iNSAOGjpSACyW6710FYiEgACtSvw From: To: , , Cc: , X-OriginalArrivalTime: 13 Jun 2002 12:28:50.0474 (UTC) FILETIME=[DF6000A0:01C212D5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA09268 Hi Glen, > > Continue operation - i.e. - not crash, and preferably not abort. > > Basically, try to have fall back operation. > > Isn't that behavior already defined in the document? I think some folks did not think this was clear enough. I think it is in the draft, but may just need to be clearer. > Maybe, maybe not: if for some reason the visted network needs the extension > to operate correctly (not that I can think of such a circumstance, but it's > hard to imagine your example, too), I would prefer denial of access to > unexplained, bizarre behavior (crash failure is almost always > preferable to Byzantine failure). Ok, lets just suggest that the result should be clear. John From owner-aaa-wg@merit.edu Thu Jun 13 09:22: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 JAA10928 for ; Thu, 13 Jun 2002 09:22:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75F1E9131D; Thu, 13 Jun 2002 09:22:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 451F79131E; Thu, 13 Jun 2002 09:22: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 47CF39131D for ; Thu, 13 Jun 2002 09:22:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A244C5DE7D; Thu, 13 Jun 2002 09:22:18 -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 34FCE5DE61 for ; Thu, 13 Jun 2002 09:22:18 -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 g5DDMKmG029035; Thu, 13 Jun 2002 15:22:20 +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 MZT3NS0C; Thu, 13 Jun 2002 15:22:12 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 15:22:12 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED23C8@eestqnt104> X-Sybari-Trust: 6144c102 2a03b045 ce6f5b63 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'john.loughney@nokia.com'" , gwz@cisco.com, randy@psg.com, dlwarren@nortelnetworks.com Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions Date: Thu, 13 Jun 2002 15:22:07 +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, Our understanding of the whole issue is that interoperability must be guaranteed by clarifications in the base protocol, not by putting requirements on vendors implementing extensions. The mechanisms defined in the protocol must be robust enough. Recommendations for at least informal documentation are acceptable, but we don't think they should be mandated. Carolina and I have checked the interoperability scenarios prepared by Bernard, and come to the following conclusions: Case 1: VSC sent from NAS to AAA server. 1a and 1c are situations in which both ends support a vendor-specific applicaton of name Frobnitz. Commands are understood and authrorazion is handled by the application. 1b. AAA server does not support Frobnitz. The client should not send Frobnitz commands, because the server has not indicated support of such application in CER/CEA. Anyway, if it does, we have the Result-Code = DIAMETER_COMMAND_UNSUPPORTED and the 'E' bit, which use is described in 7.2. No changes required. Case 2: VSC sent from AAA server to NAS. 2a. We would generalize this interoperatility problem saying that a peer sends a command and its counterpart responds with a command that is not the command expected as a response (given that the receiving side supports the request). This is independent of whether the application to which the command belongs is standard or vendor-specific. CHANGE 1. We think that it is implicit that the command code of a request and the corresponding response are always identical. This is how all the commands are defined in the base and the different applications. We could include the following clarifying text in 6.2 Diameter Answer Processing, as a new bullet: "- The same command code in the request is used in the answer." By doing this, we guarantee that a peer cannot respond with a different command. CHANGE 2 2b. We consider this case identical to 1b. Anyway, the change proposed by Bernard making clear that unsolicited VSCs sent from AAA server to NAS are to be treated as non-mandatory adds even more clarity. 2c represents no interoperability problem. To summarize, in order to solve potential interoperability problems, it is to the base protocol itself where we have to add clarifications. Mandating informal documentation is acceptable, but in the end it is the protocol who must be robust enough. Best regards, Carolina & Miguel -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: jueves, 13 de junio de 2002 11:41 To: Miguel-Angel.Pallares-Lopez@ece.ericsson.se; carolina.canales-valenzuela@ece.ericsson.se Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue Hi, We have no text in the current document that says this. Please submit text. John > -----Original Message----- > From: ext Miguel-Angel Pallares-Lopez (ECE) > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > Sent: 13 June, 2002 12:31 > To: Carolina Canales Valenzuela (ECE); 'Bernard Aboba'; Loughney John > (NRC/Helsinki) > Cc: aaa-wg@merit.edu; mankin@isi.edu > Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor > Specific Commands > Is sue > > > Exactly. Isn't the faulty case that a peer responds to a > standard command with a VSC, identical to the faulty case > where a peer responds to a standard command with a respond > not corresponding to the request? > > VSCs are not different to any other standard command with > respect to interoperability. > > BR/Miguel > > -----Original Message----- > From: Carolina Canales Valenzuela (ECE) > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > Sent: jueves, 13 de junio de 2002 11:22 > To: 'Bernard Aboba'; john.loughney@nokia.com > Cc: aaa-wg@merit.edu; mankin@isi.edu > Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor > Specific Commands > Is sue > > > Hi, > perhaps with all this discussion I've lost the point and I > don't see something that is very obvious but...why should a > NAS send a Vendor-specific command to a AAA server that > doesn't understand it, or vice-versa? > What do we have the whole CER/CEA mechanism for? (I thought > this was used to reach an agreement about the applications > that each peer understands, even if they are Vendor-specific)... > > Thank you! > Carolina > > >-----Original Message----- > >From: Bernard Aboba [mailto:aboba@internaut.com] > >Sent: Thursday, June 13, 2002 6:39 AM > >To: john.loughney@nokia.com > >Cc: aaa-wg@merit.edu; mankin@isi.edu > >Subject: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands > >Issue > > > > > >> I think the scenario would be that I am roaming and trying > >to be authenticated, > >> if the visited network implenents a vendor extension which > >prevents communication > >> to my home network because my home network does not > >implement the vendor > >> extension, then this is a bad thing. > > > >I think that it is not very hard to go through the possible > cases here, > >identify the potential interoperability problems with Vendor-Specific > >Commands, and fix them. An analysis follows. > > > >The first important thing to understand (which should > already be clear > >from the spec), is that VSCs MUST NOT be used were an existing > >command and > >vendor-specific AVPs would do the job. If this basic precept > >is followed, > >then many of the possible interoperability problems evaporate and the > >analysis becomes relatively simply. > > > >If this premise can be accepted, then presumably the vendor specific > >command is used to provide a fundamentally different service from > >existing Diameter applications. Otherwise, an existing application > >would be used with vendor-specific AVPs, which could be > >mandatory or non-mandatory. > > > >For example, addition of vendor-specific AVPs to the existing ACR/ACA > >commands does not require a vendor-specific command. However, if you > >wanted to authenticate the Frobnitz service, which requires Frobnitz > >authentication and authorization AVPs, AS WELL AS NEW CODE ON THE AAA > >SERVER, then a new command MAY be appropriate. "NEW CODE" is > >in upper case > >because in my mind this is what differentiates VSCs from > >vendor-specific > >AVPs. > > > >Given this basic understanding of when VSCs are needed, there are two > >major cases to analyze: > > > >1. VSC sent from NAS to AAA server. > >2. VSC sent from AAA server to NAS. > > > >Case 1: VSC sent from NAS to AAA server. > > > >If the NAS then sends a vendor-specific Frobnitz command to the AAA > >server, and Frobnitz is fundamentally different service, > >several outcomes > >are possible: > > > >a. The AAA server supports Frobnitz, but the user isn't > authorized for > >Frobnitz. > > > >b. The AAA server doesn't support Frobnitz. > > > >c. The AAA server supports Frobnitz, and the user is > authorized for it. > > > >In case a, the server will respond to the Frobnitz command, > >but the user > >will not be authorized. > > > >In case b, the command won't be recognized, and as a result, > >the user will > >not be allowed to access the Frobnitz service. From the user > >perspective, > >the result is indistinguishable from case a, but from the NAS > >perspective > >the difference is between receiving a Reject and receiving an Error > >Message. > > > >In case c, the user may gain access to the Frobnitz service, > >depending on > >the outcome of the authentication. > > > >Assuming that Frobnitz is really a new application, not just > >an existing > >application adorned with a VSC, then I'd claim that there is no > >interoperability problem in outcomes a-c. It would make little > >difference > >if instead of a VSC, the NAS sent an existing command with a > >NAS-Port-Type=Frobnitz. > > > >If the AAA server doesn't understand what Frobnitz is, it > >probably shouldn't be > >blindly authorizing access to it. Most AAA servers I've seen > are set up > >with policies that vary for bu NAS-Port-Type (e.g. different > >for PPP, VPN, > >802.11, Mobile IPv4, etc.), so as to reject services that the > >home server > >isn't explicitly set up for. > > > >Case 2: VSC sent from AAA server to NAS. > > > >There are several cases here: > > > >a. NAS sends a standard command to AAA server, which > responds with the > >Frobnitz VSC. > > > >b. AAA server sends an unsolicited Frobnitz command to the NAS. > > > >c. NAS sends a Frobnitz Request to the AAA server, which > >responds with a > >Frobnitz Answer. > > > >I'd claim that case a) is a legitimate interoperability > >problem and should > >be prohibited. That would require language saying "In response > >to an ACR, > >the AAA server MUST send an ACA..." I'd suggest we make sure > >that we have > >this language for all standard Diameter commands. > > > >Case b) is only an interoperability issue if the NAS were to > >change user > >state as a result of not understanding the Frobnitz command. > If the NAS > >can silently discard Frobnitz without change of state, then this is > >effectively a "non-mandatory VSC" and there is no interoperability > >problem. I'd suggest that we add some language about processing > >unsolicited VSCs. > > > >Case c) is not an interoperability issue, since both peers support > >Frobnitz. > > > >Based on this analysis, it would seem to me that the issue can > >be resolved > >with a few small changes: > > > >a. Language to make it crystal clear that VSCs MUST NOT be sent in > >response to standard commands. > > > >b. Language to make it crystal clear that unsolicited VSCs > >sent from AAA > >server to NAS are to be treated as non-mandatory. > > > >c. Language to make it clear that VSCs MUST NOT be used when > >vendor-specific AVPs could be added to standard commands instead, > >achieving the same objective. > > > From owner-aaa-wg@merit.edu Thu Jun 13 09:33: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 JAA11549 for ; Thu, 13 Jun 2002 09:33:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E8FEC9131E; Thu, 13 Jun 2002 09:33:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABF729131F; Thu, 13 Jun 2002 09:33: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 C0F1B9131E for ; Thu, 13 Jun 2002 09:33:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35FB55DE61; Thu, 13 Jun 2002 09:33:27 -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 BFD535DE46 for ; Thu, 13 Jun 2002 09:33:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5DChmI28641; Thu, 13 Jun 2002 05:43:48 -0700 Date: Thu, 13 Jun 2002 05:43:48 -0700 (PDT) From: Bernard Aboba To: "Carolina Canales Valenzuela (ECE)" Cc: john.loughney@nokia.com, , Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue In-Reply-To: <577066326047D41180AC00508B955DDA06C4536A@eestqnt104> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Hi, > perhaps with all this discussion I've lost the point and I don't see something that is very obvious but...why should a NAS send a Vendor-specific command to a AAA server that doesn't understand it, or vice-versa? > What do we have the whole CER/CEA mechanism for? (I thought this was used to reach an agreement about the applications that each peer understands, even if they are Vendor-specific)... > > Thank you! > Carolina As constituted, the CER/CEA mechanism does not prevent this. For example, the draft states that an accounting server may advertise the "Relay application." However, that doesn't mean the accounting server can handle any VSC that is thrown at it. From owner-aaa-wg@merit.edu Thu Jun 13 09:41:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11977 for ; Thu, 13 Jun 2002 09:41:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7EE79131F; Thu, 13 Jun 2002 09:41:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8505291320; Thu, 13 Jun 2002 09:41: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 980509131F for ; Thu, 13 Jun 2002 09:41:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 076765DE61; Thu, 13 Jun 2002 09:41:34 -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 7D2755DD9A for ; Thu, 13 Jun 2002 09:41:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5DCpsn29160; Thu, 13 Jun 2002 05:51:54 -0700 Date: Thu, 13 Jun 2002 05:51:54 -0700 (PDT) From: Bernard Aboba To: Daniel Warren Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mandatory Vendor-specific AVP's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Case 1 - Extending an IETF defined command by adding a Vendor Specific AVP > In this case, the AVP has to be optional. Setting the Mandatory AVP bit > would mean that all implementations would have to support this AVP in the > command and so that would no longer be vendor specific, but would rather be > a requirement. Why is this true? Vendor extensions relating to security need to be mandatory or security is compromised. We saw this with RADIUS when vendors added support for explicit filters, and NASes that didn't understand them did a silent discard, resulting in networks being provisioned without filters, with no error message to the AAA server. > Case 2 - Vendor defines a Vendor Specific Command > Within this command, the vendor is able to set Mandatory AVP's. No! Vendor Specific Commands are a last resort, since they require new code on the AAA server, whereas vendor-specific AVPs (mandatory or not) can often be added to the dictionary. So the result of using a VSC instead of a mandatory vendor-specific AVP is that only the vendor's Diameter server can be used with their NAS. > That would > indicate that if the Command is supported on an implementation, the AVP has > to be present. However, the command as a whole has to be optional so that > it does not violate interoperability with other vendor's implementations. I don't see how a legitimate VSC can be optional. If it truly represents a new kind of service, then either the AAA supports that service or not. However, I can see an unsolicited VSC sent from AAA server to NAS being optional. > These two points seem obvious to me, but I think the discussions of the last > few days have shown some confusion about what a vendor can and cannot > reasonably define and implement in terms of extensions to Diameter. > Fundamentally, the rule has to be that no peer is obliged to implement any > vendor specific extension, be it an AVP, Command, or entire application. I don't agree with this interpretation - the spec allows (and even encourages) use of vendor-specific AVPs instead of vendor-specific commands and applications. VSAs can be mandatory. From owner-aaa-wg@merit.edu Thu Jun 13 10:16: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 KAA13970 for ; Thu, 13 Jun 2002 10:16:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BCA8C91322; Thu, 13 Jun 2002 10:15:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FDD791323; Thu, 13 Jun 2002 10:15: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 2F1E991322 for ; Thu, 13 Jun 2002 10:15:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 916E55DDCF; Thu, 13 Jun 2002 10:15: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 415BD5DD9A for ; Thu, 13 Jun 2002 10:15:49 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user18.cisco.com [10.70.82.18]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA28677; Thu, 13 Jun 2002 07:15:46 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Miguel-Angel Pallares-Lopez (ECE)" , , , Cc: , Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions Date: Thu, 13 Jun 2002 07:15:42 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <577066326047D41180AC00508B955DDA05ED23C8@eestqnt104> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Miguel-Angel Pallares-Lopez (ECE) [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] writes: > Hi, > > Our understanding of the whole issue is that interoperability > must be guaranteed by clarifications in the base protocol, not by > putting requirements on vendors implementing extensions. The > mechanisms defined in the protocol must be robust enough. > Recommendations for at least informal documentation are > acceptable, but we don't think they should be mandated. > > Carolina and I have checked the interoperability scenarios > prepared by Bernard, and come to the following conclusions: > > Case 1: VSC sent from NAS to AAA server. > > 1a and 1c are situations in which both ends support a > vendor-specific applicaton of name Frobnitz. Commands are > understood and authrorazion is handled by the application. > > 1b. AAA server does not support Frobnitz. The client should not > send Frobnitz commands, because the server has not indicated > support of such application in CER/CEA. Anyway, if it does, we > have the Result-Code = DIAMETER_COMMAND_UNSUPPORTED and the 'E' > bit, which use is described in 7.2. > > No changes required. > > Case 2: VSC sent from AAA server to NAS. > > 2a. We would generalize this interoperatility problem saying that > a peer sends a command and its counterpart responds with a > command that is not the command expected as a response (given > that the receiving side supports the request). This is > independent of whether the application to which the command > belongs is standard or vendor-specific. > > CHANGE 1. > > We think that it is implicit that the command code of a request > and the corresponding response are always identical. This is how > all the commands are defined in the base and the different > applications. It is more than implicit, it's explicit. > We could include the following clarifying text in > 6.2 Diameter Answer Processing, as a new bullet: > > "- The same command code in the request is used in the answer." > > By doing this, we guarantee that a peer cannot respond with a > different command. I'm not sure that this would help. After all, section 3.1 of the current draft begins: "Each command Request/Answer pair is assigned a command code, and the sub-type (i.e. - request or answer) is identified via the 'R' bit in the Command Flags field of the Diameter header", and section 3.3 says "Both the request and the answer for a given command share the same command code. The request is identified by the R(equest) bit in the Diameter header set to one (1), to ask that a particular action be performed, such as authorizing a user or terminating a session. Once the receiver has completed the request it issues the corresponding answer...". These passages seem to me to say almost exactly the same thing as your suggested text, and quite clearly. I guess it's not clear to me how even further repetition is going help. > > CHANGE 2 > > 2b. We consider this case identical to 1b. Anyway, the change > proposed by Bernard making clear that unsolicited VSCs sent from > AAA server to NAS are to be treated as non-mandatory adds even > more clarity. I'd _really_ like it if someone could show where in base-11 it even suggests that a VSC can be "mandatory". > > 2c represents no interoperability problem. > > > To summarize, in order to solve potential interoperability > problems, it is to the base protocol itself where we have to add > clarifications. Mandating informal documentation is acceptable, > but in the end it is the protocol who must be robust enough. > > Best regards, > Carolina & Miguel > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: jueves, 13 de junio de 2002 11:41 > To: Miguel-Angel.Pallares-Lopez@ece.ericsson.se; > carolina.canales-valenzuela@ece.ericsson.se > Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands > Is sue > > > Hi, > > We have no text in the current document that says this. > Please submit text. > > John > > > -----Original Message----- > > From: ext Miguel-Angel Pallares-Lopez (ECE) > > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > > Sent: 13 June, 2002 12:31 > > To: Carolina Canales Valenzuela (ECE); 'Bernard Aboba'; Loughney John > > (NRC/Helsinki) > > Cc: aaa-wg@merit.edu; mankin@isi.edu > > Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor > > Specific Commands > > Is sue > > > > > > Exactly. Isn't the faulty case that a peer responds to a > > standard command with a VSC, identical to the faulty case > > where a peer responds to a standard command with a respond > > not corresponding to the request? > > > > VSCs are not different to any other standard command with > > respect to interoperability. > > > > BR/Miguel > > > > -----Original Message----- > > From: Carolina Canales Valenzuela (ECE) > > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > > Sent: jueves, 13 de junio de 2002 11:22 > > To: 'Bernard Aboba'; john.loughney@nokia.com > > Cc: aaa-wg@merit.edu; mankin@isi.edu > > Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor > > Specific Commands > > Is sue > > > > > > Hi, > > perhaps with all this discussion I've lost the point and I > > don't see something that is very obvious but...why should a > > NAS send a Vendor-specific command to a AAA server that > > doesn't understand it, or vice-versa? > > What do we have the whole CER/CEA mechanism for? (I thought > > this was used to reach an agreement about the applications > > that each peer understands, even if they are Vendor-specific)... > > > > Thank you! > > Carolina > > > > >-----Original Message----- > > >From: Bernard Aboba [mailto:aboba@internaut.com] > > >Sent: Thursday, June 13, 2002 6:39 AM > > >To: john.loughney@nokia.com > > >Cc: aaa-wg@merit.edu; mankin@isi.edu > > >Subject: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands > > >Issue > > > > > > > > >> I think the scenario would be that I am roaming and trying > > >to be authenticated, > > >> if the visited network implenents a vendor extension which > > >prevents communication > > >> to my home network because my home network does not > > >implement the vendor > > >> extension, then this is a bad thing. > > > > > >I think that it is not very hard to go through the possible > > cases here, > > >identify the potential interoperability problems with Vendor-Specific > > >Commands, and fix them. An analysis follows. > > > > > >The first important thing to understand (which should > > already be clear > > >from the spec), is that VSCs MUST NOT be used were an existing > > >command and > > >vendor-specific AVPs would do the job. If this basic precept > > >is followed, > > >then many of the possible interoperability problems evaporate and the > > >analysis becomes relatively simply. > > > > > >If this premise can be accepted, then presumably the vendor specific > > >command is used to provide a fundamentally different service from > > >existing Diameter applications. Otherwise, an existing application > > >would be used with vendor-specific AVPs, which could be > > >mandatory or non-mandatory. > > > > > >For example, addition of vendor-specific AVPs to the existing ACR/ACA > > >commands does not require a vendor-specific command. However, if you > > >wanted to authenticate the Frobnitz service, which requires Frobnitz > > >authentication and authorization AVPs, AS WELL AS NEW CODE ON THE AAA > > >SERVER, then a new command MAY be appropriate. "NEW CODE" is > > >in upper case > > >because in my mind this is what differentiates VSCs from > > >vendor-specific > > >AVPs. > > > > > >Given this basic understanding of when VSCs are needed, there are two > > >major cases to analyze: > > > > > >1. VSC sent from NAS to AAA server. > > >2. VSC sent from AAA server to NAS. > > > > > >Case 1: VSC sent from NAS to AAA server. > > > > > >If the NAS then sends a vendor-specific Frobnitz command to the AAA > > >server, and Frobnitz is fundamentally different service, > > >several outcomes > > >are possible: > > > > > >a. The AAA server supports Frobnitz, but the user isn't > > authorized for > > >Frobnitz. > > > > > >b. The AAA server doesn't support Frobnitz. > > > > > >c. The AAA server supports Frobnitz, and the user is > > authorized for it. > > > > > >In case a, the server will respond to the Frobnitz command, > > >but the user > > >will not be authorized. > > > > > >In case b, the command won't be recognized, and as a result, > > >the user will > > >not be allowed to access the Frobnitz service. From the user > > >perspective, > > >the result is indistinguishable from case a, but from the NAS > > >perspective > > >the difference is between receiving a Reject and receiving an Error > > >Message. > > > > > >In case c, the user may gain access to the Frobnitz service, > > >depending on > > >the outcome of the authentication. > > > > > >Assuming that Frobnitz is really a new application, not just > > >an existing > > >application adorned with a VSC, then I'd claim that there is no > > >interoperability problem in outcomes a-c. It would make little > > >difference > > >if instead of a VSC, the NAS sent an existing command with a > > >NAS-Port-Type=Frobnitz. > > > > > >If the AAA server doesn't understand what Frobnitz is, it > > >probably shouldn't be > > >blindly authorizing access to it. Most AAA servers I've seen > > are set up > > >with policies that vary for bu NAS-Port-Type (e.g. different > > >for PPP, VPN, > > >802.11, Mobile IPv4, etc.), so as to reject services that the > > >home server > > >isn't explicitly set up for. > > > > > >Case 2: VSC sent from AAA server to NAS. > > > > > >There are several cases here: > > > > > >a. NAS sends a standard command to AAA server, which > > responds with the > > >Frobnitz VSC. > > > > > >b. AAA server sends an unsolicited Frobnitz command to the NAS. > > > > > >c. NAS sends a Frobnitz Request to the AAA server, which > > >responds with a > > >Frobnitz Answer. > > > > > >I'd claim that case a) is a legitimate interoperability > > >problem and should > > >be prohibited. That would require language saying "In response > > >to an ACR, > > >the AAA server MUST send an ACA..." I'd suggest we make sure > > >that we have > > >this language for all standard Diameter commands. > > > > > >Case b) is only an interoperability issue if the NAS were to > > >change user > > >state as a result of not understanding the Frobnitz command. > > If the NAS > > >can silently discard Frobnitz without change of state, then this is > > >effectively a "non-mandatory VSC" and there is no interoperability > > >problem. I'd suggest that we add some language about processing > > >unsolicited VSCs. > > > > > >Case c) is not an interoperability issue, since both peers support > > >Frobnitz. > > > > > >Based on this analysis, it would seem to me that the issue can > > >be resolved > > >with a few small changes: > > > > > >a. Language to make it crystal clear that VSCs MUST NOT be sent in > > >response to standard commands. > > > > > >b. Language to make it crystal clear that unsolicited VSCs > > >sent from AAA > > >server to NAS are to be treated as non-mandatory. > > > > > >c. Language to make it clear that VSCs MUST NOT be used when > > >vendor-specific AVPs could be added to standard commands instead, > > >achieving the same objective. > > > > > > > From owner-aaa-wg@merit.edu Thu Jun 13 10:25:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14579 for ; Thu, 13 Jun 2002 10:25:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 686D891323; Thu, 13 Jun 2002 10:25:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2956691324; Thu, 13 Jun 2002 10:25:46 -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 D19AF91323 for ; Thu, 13 Jun 2002 10:25:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48BF55DDCF; Thu, 13 Jun 2002 10:25:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 7FD5C5DD9A for ; Thu, 13 Jun 2002 10:25:39 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DEPXV16501; Thu, 13 Jun 2002 16:25:33 +0200 (MEST) 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 g5DEPQe03728; Thu, 13 Jun 2002 15:25:27 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 15:25:30 +0100 Message-ID: From: "Daniel Warren" To: "'gwz@cisco.com'" , "Miguel-Angel Pallares-Lopez (ECE)" , john.loughney@nokia.com, randy@psg.com Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extens ions Date: Thu, 13 Jun 2002 15:25:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212E6.2A602ADE" 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_01C212E6.2A602ADE Content-Type: text/plain; charset="iso-8859-1" > I'd _really_ like it if someone could show where in base-11 it even suggests > that a VSC can be "mandatory". Me too... ------_=_NextPart_001_01C212E6.2A602ADE Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions

> I'd _really_ like it if someone could show where in base-11 it even suggests
> that a VSC can be "mandatory".


Me too...

------_=_NextPart_001_01C212E6.2A602ADE-- From owner-aaa-wg@merit.edu Thu Jun 13 10:29: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 KAA14815 for ; Thu, 13 Jun 2002 10:29:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89D4291324; Thu, 13 Jun 2002 10:30:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1776591326; Thu, 13 Jun 2002 10:30: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 1120291324 for ; Thu, 13 Jun 2002 10:30:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7DB435DDCF; Thu, 13 Jun 2002 10:29:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id A29065DD9A for ; Thu, 13 Jun 2002 10:29:55 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DEU2V17572; Thu, 13 Jun 2002 16:30:02 +0200 (MEST) 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 g5DEU0e04486; Thu, 13 Jun 2002 15:30:01 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 15:30:04 +0100 Message-ID: From: "Daniel Warren" To: "'Bernard Aboba'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's Date: Thu, 13 Jun 2002 15:29:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212E6.CB72A924" 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_01C212E6.CB72A924 Content-Type: text/plain; charset="iso-8859-1" > > Case 1 - Extending an IETF defined command by adding a Vendor Specific AVP > > In this case, the AVP has to be optional. Setting the Mandatory AVP bit > > would mean that all implementations would have to support this AVP in the > > command and so that would no longer be vendor specific, but would rather be > > a requirement. > > Why is this true? Vendor extensions relating to security need to be > mandatory or security is compromised. We saw this with RADIUS when vendors > added support for explicit filters, and NASes that didn't understand them > did a silent discard, resulting in networks being provisioned without > filters, with no error message to the AAA server. An example. Vendor A implements a Vendor Specific AVP. For whatever reason, this AVP gets sent to a peer made by Vendor B, which does not understand or recognise this AVP (because it is identified with Vendor A's vendor-id). For interoperability, Vendor A's AVP must not affect the successful undertanding of the command by Vendor B's equipment. Therefore, the AVP must be optional so that Vendor B's equipment is allowed to ignore it - if it were mandatory, Vendor B (and any other vendor's) equipment would have to be able to understand the AVP else the command would fail. That means the AVP is no longer vendor specific, because every vendor has to implement it because it is a mandatory requirement. > > > Case 2 - Vendor defines a Vendor Specific Command > > Within this command, the vendor is able to set Mandatory AVP's. > No! Vendor Specific Commands are a last resort I agree! > , since they require new > code on the AAA server, whereas vendor-specific AVPs (mandatory or not) > can often be added to the dictionary. So the result of using a VSC instead > of a mandatory vendor-specific AVP is that only the vendor's Diameter > server can be used with their NAS. Not if the command is optional. Again, if vendor A's server has implemented a command that it uses towards vendor A's NAS and also towards vendor B's NAS as well, it will advertise that capability in the CER. Vendor A's NAS will respond with the command code confirming support of the VSC, whilst vendor B's NAS will not. The VSC is not allowed to affect interoperability, so Vendor A's server and Vendor B's NAS still have to be able to work without the VSC of vendor A. Therefore the VSC has to be optional. > > > That would > > indicate that if the Command is supported on an implementation, the AVP has > > to be present. However, the command as a whole has to be optional so that > > it does not violate interoperability with other vendor's implementations. > > I don't see how a legitimate VSC can be optional. If it truly represents a > new kind of service, then either the AAA supports that service or not. > However, I can see an unsolicited VSC sent from AAA server to NAS being > optional. For interoperability, operation has to be able to continue when VSC or VSAVP are ignored by the receiving node if that node does not understand them. Therefore they must be optional. > > > These two points seem obvious to me, but I think the discussions of the last > > few days have shown some confusion about what a vendor can and cannot > > reasonably define and implement in terms of extensions to Diameter. > > > > Fundamentally, the rule has to be that no peer is obliged to implement any > > vendor specific extension, be it an AVP, Command, or entire application. > > I don't agree with this interpretation - the spec allows (and even > encourages) use of vendor-specific AVPs instead of vendor-specific > commands and applications. VSAs can be mandatory. If a VSA is mandatory, then every vendor's equipment has to be able to receive it and understand it's meaning. If every vendor has to implement the VENDOR SPECIFIC AVP, then it isn't vendor specific anymore, it is vendor agnostic. The only other way I can conceive of making my point is to ask what the situation is with an AVP, marked as mandatory, which is defined in an IETF Diameter Application. If a server sends this to a NAS, the server must be able to expect the NAS to understand it. If the NAS doesn't understand the AVP, then because the AVP is essential to the operation (else it would not be marked as mandatory), the command would fail. Similarly, by allowing a VSA to be mandatory, the server must be able to expect the NAS to understand the VSA. If the NAS does not understand the VSA, again it has to fail the command, because if the VSA was not essential to the operation, it would not be mandatory. But to maintain interop, the NAS has to be able to complete the command without the VSA. Hence there is a contradiction in the logic. Mandatory implies understanding, but interop requires it to be ignored. You can't have both. ------_=_NextPart_001_01C212E6.CB72A924 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Mandatory Vendor-specific AVP's

> > Case 1 - Extending an IETF defined command = by adding a Vendor Specific AVP
> > In this case, the AVP has to be = optional.  Setting the Mandatory AVP bit
> > would mean that all implementations would = have to support this AVP in the
> > command and so that would no longer be = vendor specific, but would rather be
> > a requirement.
>
> Why is this true? Vendor extensions relating to = security need to be
> mandatory or security is compromised. We saw = this with RADIUS when vendors
> added support for explicit filters, and NASes = that didn't understand them
> did a silent discard, resulting in networks = being provisioned without
> filters, with no error message to the AAA = server.

An example.  Vendor A implements a Vendor = Specific AVP.  For whatever reason, this AVP gets sent to a peer = made by Vendor B, which does not understand or recognise this AVP = (because it is identified with Vendor A's vendor-id).  For = interoperability, Vendor A's AVP must not affect the successful = undertanding of the command by Vendor B's equipment.  Therefore, = the AVP must be optional so that Vendor B's equipment is allowed to = ignore it - if it were mandatory, Vendor B (and any other vendor's) = equipment would have to be able to understand the AVP else the command = would fail.  That means the AVP is no longer vendor specific, = because every vendor has to implement it because it is a mandatory = requirement.

>
> > Case 2 - Vendor defines a Vendor Specific = Command
> > Within this command, the vendor is able to = set Mandatory AVP's.

> No! Vendor Specific Commands are a last = resort
I agree!

> , since they require new
> code on the AAA server, whereas vendor-specific = AVPs (mandatory or not)
> can often be added to the dictionary. So the = result of using a VSC instead
> of a mandatory vendor-specific AVP is that only = the vendor's Diameter
> server can be used with their NAS.

Not if the command is optional.  Again, if = vendor A's server has implemented a command that it uses towards vendor = A's NAS and also towards vendor B's NAS as well, it will advertise that = capability in the CER.  Vendor A's NAS will respond with the = command code confirming support of the VSC, whilst vendor B's NAS will = not. The VSC is not allowed to affect interoperability, so Vendor A's = server and Vendor B's NAS still have to be able to work without the VSC = of vendor A.  Therefore the VSC has to be optional.

>
> > That would
> > indicate that if the Command is supported = on an implementation, the AVP has
> > to be present.  However, the command = as a whole has to be optional so that
> > it does not violate interoperability with = other vendor's implementations.
>
> I don't see how a legitimate VSC can be = optional. If it truly represents a
> new kind of service, then either the AAA = supports that service or not.
> However, I can see an unsolicited VSC sent from = AAA server to NAS being
> optional.

For interoperability, operation has to be able to = continue when VSC or VSAVP are ignored by the receiving node if that = node does not understand them.  Therefore they must be = optional.

>
> > These two points seem obvious to me, but I = think the discussions of the last
> > few days have shown some confusion about = what a vendor can and cannot
> > reasonably define and implement in terms = of extensions to Diameter.
>
>
> > Fundamentally, the rule has to be that no = peer is obliged to implement any
> > vendor specific extension, be it an AVP, = Command, or entire application.
>
> I don't agree with this interpretation - the = spec allows (and even
> encourages) use of vendor-specific AVPs instead = of vendor-specific
> commands and applications. VSAs can be = mandatory.

If a VSA is mandatory, then every vendor's equipment = has to be able to receive it and understand it's meaning.  If = every vendor has to implement the VENDOR SPECIFIC AVP, then it isn't = vendor specific anymore, it is vendor agnostic.

The only other way I can conceive of making my point = is to ask what the situation is with an AVP, marked as mandatory, which = is defined in an IETF Diameter Application.  If a server sends = this to a NAS, the server must be able to expect the NAS to understand = it.  If the NAS doesn't understand the AVP, then because the AVP = is essential to the operation (else it would not be marked as = mandatory), the command would fail.  Similarly, by allowing a VSA = to be mandatory, the server  must be able to expect the NAS to = understand the VSA.  If the NAS does not understand the VSA, again = it has to fail the command, because if the VSA was not essential to the = operation, it would not be mandatory.  But to maintain interop, = the NAS has to be able to complete the command without the VSA.  = Hence there is a contradiction in the logic.  Mandatory implies = understanding, but interop requires it to be ignored.  You can't = have both. 

------_=_NextPart_001_01C212E6.CB72A924-- From owner-aaa-wg@merit.edu Thu Jun 13 10:35:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15144 for ; Thu, 13 Jun 2002 10:35:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8352B91325; Thu, 13 Jun 2002 10:36:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E61491326; Thu, 13 Jun 2002 10:36: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 40E2A91325 for ; Thu, 13 Jun 2002 10:36:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A584A5DE5F; Thu, 13 Jun 2002 10:35:59 -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 273F05DD9A for ; Thu, 13 Jun 2002 10:35:59 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user18.cisco.com [10.70.82.18]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA20999; Thu, 13 Jun 2002 07:35:56 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Carolina Canales Valenzuela (ECE)" Cc: , , Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue Date: Thu, 13 Jun 2002 07:35:54 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > Hi, > > perhaps with all this discussion I've lost the point and I > don't see something that is very obvious but...why should a NAS > send a Vendor-specific command to a AAA server that doesn't > understand it, or vice-versa? > > What do we have the whole CER/CEA mechanism for? (I thought > this was used to reach an agreement about the applications that > each peer understands, even if they are Vendor-specific)... > > > > Thank you! > > Carolina > > As constituted, the CER/CEA mechanism does not prevent this. For example, > the draft states that an accounting server may advertise the "Relay > application." However, that doesn't mean the accounting server can handle > any VSC that is thrown at it. Actually, I think it does. Section 2 says "Diameter Relays and Redirect agents are, by definition, protocol transparent, and MUST transparently support the Diameter base protocol, which includes accounting, and all Diameter applications.", and section 1.2.4 says, "Note that the creation of a new application should be viewed as a last resort and should be used only when Vendor-Specific AVPs are insufficient. In most cases, reusing an existing Application ID with Vendor-Specific AVPs should work. For example, many accounting servers are set up to write AVPs to disk, so they can handle even mandatory vendor-specific AVPs that they don't understand. This is why "disk writing" accounting servers should advertise themselves as "Relays" that can handle any Application ID, including Vendor-Specific." Since what exemplifies a Diameter application is the definition of "at least one Command Code", it sure sounds like the hypothetical accounting server better be able to handle anything; either that, or we redefine the term "relay". > > > From owner-aaa-wg@merit.edu Thu Jun 13 10:46: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 KAA15667 for ; Thu, 13 Jun 2002 10:46:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCF5491327; Thu, 13 Jun 2002 10:46:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC1EC91328; Thu, 13 Jun 2002 10:46: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 4958391327 for ; Thu, 13 Jun 2002 10:46:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A8AC75DDF9; Thu, 13 Jun 2002 10:46:28 -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 2A8BA5DD9A for ; Thu, 13 Jun 2002 10:46:28 -0400 (EDT) Received: from GWZW2K (tokyo-vpn-user18.cisco.com [10.70.82.18]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA02611; Thu, 13 Jun 2002 07:46:02 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Daniel Warren" Cc: Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's Date: Thu, 13 Jun 2002 07:46:00 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto://aboba@internaut.com] writes: > > Case 1 - Extending an IETF defined command by adding a Vendor > Specific AVP > > In this case, the AVP has to be optional. Setting the Mandatory AVP bit > > would mean that all implementations would have to support this > AVP in the > > command and so that would no longer be vendor specific, but > would rather be > > a requirement. > > Why is this true? Vendor extensions relating to security need to be > mandatory or security is compromised. We saw this with RADIUS when vendors > added support for explicit filters, and NASes that didn't understand them > did a silent discard, resulting in networks being provisioned without > filters, with no error message to the AAA server. I think that the problem here arose less from the lack of support for the attribute than from the overly taciturn nature of RADIUS. This problem shouldn't arise with Diameter, since it _will_ return an error message. > > > Case 2 - Vendor defines a Vendor Specific Command > > Within this command, the vendor is able to set Mandatory AVP's. > > No! Vendor Specific Commands are a last resort, since they require new > code on the AAA server, whereas vendor-specific AVPs (mandatory or not) > can often be added to the dictionary. So the result of using a VSC instead > of a mandatory vendor-specific AVP is that only the vendor's Diameter > server can be used with their NAS. > > > That would > > indicate that if the Command is supported on an implementation, > the AVP has > > to be present. However, the command as a whole has to be > optional so that > > it does not violate interoperability with other vendor's > implementations. > > I don't see how a legitimate VSC can be optional. If it truly represents a > new kind of service, then either the AAA supports that service or not. Exactly; I would call that "optional", as opposed to standard commands which are by nature mandatory. If the AAA doesn't support the standard commands, it doesn't support Diameter, but if it lacks support for some (or any) VSCs and does support the standard command set, it still supports Diameter. > However, I can see an unsolicited VSC sent from AAA server to NAS being > optional. > > > These two points seem obvious to me, but I think the > discussions of the last > > few days have shown some confusion about what a vendor can and cannot > > reasonably define and implement in terms of extensions to Diameter. > > > > Fundamentally, the rule has to be that no peer is obliged to > implement any > > vendor specific extension, be it an AVP, Command, or entire application. > > I don't agree with this interpretation - the spec allows (and even > encourages) use of vendor-specific AVPs instead of vendor-specific > commands and applications. VSAs can be mandatory. I agree. > > > From owner-aaa-wg@merit.edu Thu Jun 13 10:55: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 KAA15952 for ; Thu, 13 Jun 2002 10:55:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80E9291328; Thu, 13 Jun 2002 10:55:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 541F49132A; Thu, 13 Jun 2002 10:55: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 4CAEF91328 for ; Thu, 13 Jun 2002 10:55:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA2435DE06; Thu, 13 Jun 2002 10:55:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id 56D645DD9A for ; Thu, 13 Jun 2002 10:55:13 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5DEtIB15283; Thu, 13 Jun 2002 10:55:18 -0400 (EDT) Received: from mccap-1.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA26840; Thu, 13 Jun 2002 09:55:17 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GXNG44-0000F0-00; Thu, 13 Jun 2002 10:55:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.45651.63806.521261@gargle.gargle.HOWL> Date: Thu, 13 Jun 2002 09:55:15 -0500 From: Pete McCann To: Cc: Subject: [AAA-WG]: Base Updated section 1.2 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E57@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E57@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 Hi, I think some of the text below regarding Application IDs is inconsistent. Let me point it out, and then ask a question which I think will help clear up some of the confusion I see in the recent discussions. john.loughney@nokia.com writes: ... > 1.2.4 Creating New Authentication Applications ... > Every Diameter application specification MUST have an IANA assigned > Application Identifier (see section 2.4). > > 1.2.5 Creating New Accounting Applications > ... > process. Every accounting application MUST have either an IANA > allocated Application Identifier, or a vendor specific Application > Identifier. > ... > Every Diameter accounting application specification MUST have an IANA > assigned Application Identifier (see section 2.4). So apparently Accounting applications are allowed to have vendor specific Application IDs, but Auth Applications are not. Was this the intention? My opinion is that the final sentence of each of these sections should read: Every Diameter [authentication,accounting] application MUST have an IANA assigned Application Identifier, or a vendor specific Application Identifier. Much of the discussion recently has focused on vendor-specific *commands* inside standard applications, but I want to make sure we retain the ability to define new vendor-specific *applications* as well. Note that I do not think there are any interoperability concerns here, because both sides must explicitly indicate support for a vendor-specific application before any of the commands belonging to the application can be sent. These applications never constitute "changes" or "modifications" to the Diameter base protocol or to any standard application. Would that be acceptable to the IESG? -Pete From owner-aaa-wg@merit.edu Thu Jun 13 11:09: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 LAA16767 for ; Thu, 13 Jun 2002 11:09:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E4259132B; Thu, 13 Jun 2002 11:09:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E09F9132E; Thu, 13 Jun 2002 11:09: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 1CA689132B for ; Thu, 13 Jun 2002 11:09:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E87A5DE61; Thu, 13 Jun 2002 11:09:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 2F8A55DD9A for ; Thu, 13 Jun 2002 11:09:27 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5DF9TJ23804; Thu, 13 Jun 2002 11:09:29 -0400 (EDT) Received: from mccap-1.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA06346; Thu, 13 Jun 2002 10:09:28 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GXNGRR-00016C-00; Thu, 13 Jun 2002 11:09:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.46501.797218.24774@gargle.gargle.HOWL> Date: Thu, 13 Jun 2002 10:09:25 -0500 From: Pete McCann To: "Daniel Warren" Cc: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's 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 Daniel Warren writes: > > I don't agree with this interpretation - the spec allows (and even > > encourages) use of vendor-specific AVPs instead of vendor-specific > > commands and applications. VSAs can be mandatory. > > If a VSA is mandatory, then every vendor's equipment has to be able to > receive it and understand it's meaning. Not true. Don't confuse the 'M bit' with a "MUST implement" requirement. The 'M bit' only means, "if you don't understand the VSA, you must fail the command." > If the NAS does not understand the VSA, again it has to fail the > command, because if the VSA was not essential to the operation, it > would not be mandatory. But to maintain interop, the NAS has to be > able to complete the command without the VSA. Hence there is a > contradiction in the logic. Mandatory implies understanding, but > interop requires it to be ignored. You can't have both. I think Bernard's point was that failing a command is a perfectly valid way to interop, especially for security-related commands. If the sender gets a failure indication, it can try something else, like re-sending the command without the offending VSA, or giving up. -Pete From owner-aaa-wg@merit.edu Thu Jun 13 11:20:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17241 for ; Thu, 13 Jun 2002 11:20:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 087679122C; Thu, 13 Jun 2002 11:21:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA6829132D; Thu, 13 Jun 2002 11:21:06 -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 B20AA9122C for ; Thu, 13 Jun 2002 11:21:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DB9D5DE5F; Thu, 13 Jun 2002 11:21:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id 64C5E5DD9A for ; Thu, 13 Jun 2002 11:21:01 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DFL8V11464; Thu, 13 Jun 2002 17:21:08 +0200 (MEST) 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 g5DFL6e20240; Thu, 13 Jun 2002 16:21:06 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 16:21:10 +0100 Message-ID: From: "Daniel Warren" To: "'Pete McCann'" Cc: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's Date: Thu, 13 Jun 2002 16:21:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212ED.ECFF9B5E" 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_01C212ED.ECFF9B5E Content-Type: text/plain; charset="iso-8859-1" Daniel Warren writes: > > > I don't agree with this interpretation - the spec allows (and even > > > encourages) use of vendor-specific AVPs instead of vendor-specific > > > commands and applications. VSAs can be mandatory. > > > > If a VSA is mandatory, then every vendor's equipment has to be able to > > receive it and understand it's meaning. > > Not true. Don't confuse the 'M bit' with a "MUST implement" > requirement. The 'M bit' only means, "if you don't understand the > VSA, you must fail the command." > > > If the NAS does not understand the VSA, again it has to fail the > > command, because if the VSA was not essential to the operation, it > > would not be mandatory. But to maintain interop, the NAS has to be > > able to complete the command without the VSA. Hence there is a > > contradiction in the logic. Mandatory implies understanding, but > > interop requires it to be ignored. You can't have both. > > I think Bernard's point was that failing a command is a perfectly > valid way to interop, especially for security-related commands. If > the sender gets a failure indication, it can try something else, like > re-sending the command without the offending VSA, or giving up. > OK, I can see that point, but mandatory in my mind is with regard to the inclusion of the AVP in the command. If an AVP (be it standardised or VSA) is mandatory it has to be in the command as it is essential to the successful completion of the command. If you are giving the sender the option of trying again without the VSA, then it is not mandatory, it is optional, because you have the option to leave it out without affecting the completion of the command. ------_=_NextPart_001_01C212ED.ECFF9B5E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Mandatory Vendor-specific AVP's

Daniel Warren writes:
> > > I don't agree with this = interpretation - the spec allows (and even
> > > encourages) use of vendor-specific = AVPs instead of vendor-specific
> > > commands and applications. VSAs can = be mandatory.
> >
> > If a VSA is mandatory, then every vendor's = equipment has to be able to
> > receive it and understand it's = meaning.
>
> Not true.  Don't confuse the 'M bit' with = a "MUST implement"
> requirement.  The 'M bit' only means, = "if you don't understand the
> VSA, you must fail the command."
>
> > If the NAS does not understand the VSA, = again it has to fail the
> > command, because if the VSA was not = essential to the operation, it
> > would not be mandatory.  But to = maintain interop, the NAS has to be
> > able to complete the command without the = VSA.  Hence there is a
> > contradiction in the logic.  = Mandatory implies understanding, but
> > interop requires it to be ignored.  = You can't have both.
>
> I think Bernard's point was that failing a = command is a perfectly
> valid way to interop, especially for = security-related commands.  If
> the sender gets a failure indication, it can = try something else, like
> re-sending the command without the offending = VSA, or giving up.
>

OK, I can see that point, but mandatory in my mind is = with regard to the inclusion of the AVP in the command.  If an AVP = (be it standardised or VSA) is mandatory it has to be in the command as = it is essential to the successful completion of the command.  If = you are giving the sender the option of trying again without the VSA, = then it is not mandatory, it is optional, because you have the option = to leave it out without affecting the completion of the = command.


------_=_NextPart_001_01C212ED.ECFF9B5E-- From owner-aaa-wg@merit.edu Thu Jun 13 11:35:00 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 LAA17843 for ; Thu, 13 Jun 2002 11:35:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96EA99132E; Thu, 13 Jun 2002 11:35:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31C9E91330; Thu, 13 Jun 2002 11:35:12 -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 014239132E for ; Thu, 13 Jun 2002 11:35:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CFF65DE74; Thu, 13 Jun 2002 11:35:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 1DAEB5DE5F for ; Thu, 13 Jun 2002 11:35:07 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5DFZAJ09070; Thu, 13 Jun 2002 11:35:10 -0400 (EDT) Received: from mccap-1.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA21977; Thu, 13 Jun 2002 10:35:09 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GXNHYK-0001IW-00; Thu, 13 Jun 2002 11:35:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15624.48042.813389.505452@gargle.gargle.HOWL> Date: Thu, 13 Jun 2002 10:35:06 -0500 From: Pete McCann To: "Daniel Warren" Cc: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's 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 Daniel Warren writes: > > OK, I can see that point, but mandatory in my mind is with regard to the > inclusion of the AVP in the command. If an AVP (be it standardised or VSA) > is mandatory it has to be in the command as it is essential to the > successful completion of the command. If you are giving the sender the > option of trying again without the VSA, then it is not mandatory, it is > optional, because you have the option to leave it out without affecting the > completion of the command. Ah, but the retry need not be exactly the original minus the VSA. It might change other aspects of the command, so that, for example, if the NAS didn't implement the super-terrific-proprietary-security mechanism, it could fall back to the not-quite-as-terrific-but-standardized security mechanism (not such a good example, as it might be open to bidding-down attacks, but you get the idea). Or, the sender could try a completely different command instead. I agree that all VSAs in standard commands must be "optional" in the sense that the ABNF would use [], not {}. But this doesn't have anything to do with the setting of the M-bit. -Pete From owner-aaa-wg@merit.edu Thu Jun 13 11:57: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 LAA18925 for ; Thu, 13 Jun 2002 11:57:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 372F691330; Thu, 13 Jun 2002 11:57:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 024D991331; Thu, 13 Jun 2002 11:57: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 DCB5F91330 for ; Thu, 13 Jun 2002 11:57:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5903B5DE5F; Thu, 13 Jun 2002 11:57:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by segue.merit.edu (Postfix) with ESMTP id A94125DD9A for ; Thu, 13 Jun 2002 11:57:28 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DFvaV18158; Thu, 13 Jun 2002 17:57:36 +0200 (MEST) 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 g5DFvYe24706; Thu, 13 Jun 2002 16:57:34 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 16:57:38 +0100 Message-ID: From: "Daniel Warren" To: "'Pete McCann'" Cc: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's Date: Thu, 13 Jun 2002 16:57:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212F3.06A5C3F8" 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_01C212F3.06A5C3F8 Content-Type: text/plain; charset="iso-8859-1" > > OK, I can see that point, but mandatory in my mind is with regard to the > > inclusion of the AVP in the command. If an AVP (be it standardised or VSA) > > is mandatory it has to be in the command as it is essential to the > > successful completion of the command. If you are giving the sender the > > option of trying again without the VSA, then it is not mandatory, it is > > optional, because you have the option to leave it out without affecting the > > completion of the command. > > Ah, but the retry need not be exactly the original minus the VSA. It > might change other aspects of the command, so that, for example, if > the NAS didn't implement the super-terrific-proprietary-security > mechanism, it could fall back to the not-quite-as-terrific-but-standardized > security mechanism (not such a good example, as it might be open to > bidding-down attacks, but you get the idea). Or, the sender could try > a completely different command instead. > > I agree that all VSAs in standard commands must be "optional" in the > sense that the ABNF would use [], not {}. But this doesn't have > anything to do with the setting of the M-bit. > > -Pete Ah ha! So we have got to the bottom of this and (as I was a beginning to suspect) it comes down to my personal confusion. I certainly can see the point you make with regard to the retry. The bit (no pun intended) that has really had me baffled is how you could have the M-bit set but not include the AVP all the time. The 'real' optionality of an AVP in a command is indicated in the ABNF, so you could set an M-bit for an AVP contained in []'s. In summary, setting the Mandatory bit doesn't mandate inclusion of the AVP, rather it mandates that the receiver must understand the AVP, or else fail the command. To make sure I am 100% clear, when Bernard and others refer to a Mandatory VSA, we are talking about setting the M bit, and not mandatory inclusion. If that is the case I think I have got my understanding straight. I'm not saying it's logical, but I think I get it. Dan ------_=_NextPart_001_01C212F3.06A5C3F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Mandatory Vendor-specific AVP's

> > OK, I can see that point, but mandatory in = my mind is with regard to the
> > inclusion of the AVP in the command.  = If an AVP (be it standardised or VSA)
> > is mandatory it has to be in the command = as it is essential to the
> > successful completion of the = command.  If you are giving the sender the
> > option of trying again without the VSA, = then it is not mandatory, it is
> > optional, because you have the option to = leave it out without affecting the
> > completion of the command.
>
> Ah, but the retry need not be exactly the = original minus the VSA.  It
> might change other aspects of the command, so = that, for example, if
> the NAS didn't implement the = super-terrific-proprietary-security
> mechanism, it could fall back to the = not-quite-as-terrific-but-standardized
> security mechanism (not such a good example, as = it might be open to
> bidding-down attacks, but you get the = idea).  Or, the sender could try
> a completely different command instead.
>
> I agree that all VSAs in standard commands must = be "optional" in the
> sense that the ABNF would use [], not {}.  = But this doesn't have
> anything to do with the setting of the = M-bit.
>
> -Pete

Ah ha!  So we have got to the bottom of this and = (as I was a beginning to suspect) it comes down to my personal = confusion.  I certainly can see the point you make with regard to = the retry.  The bit (no pun intended) that has really had me = baffled is how you could have the M-bit set but not include the AVP all = the time.  The 'real' optionality of an AVP in a command is = indicated in the ABNF, so you could set an M-bit for an AVP contained = in []'s.

In summary, setting the Mandatory bit doesn't mandate = inclusion of the AVP, rather it mandates that the receiver must = understand the AVP, or else fail the command.  To make sure I am = 100% clear, when Bernard and others refer to a Mandatory VSA, we are = talking about setting the M bit, and not mandatory inclusion.  If = that is the case I think I have got my understanding straight.  = I'm not saying it's logical, but I think I get it.

Dan

------_=_NextPart_001_01C212F3.06A5C3F8-- From owner-aaa-wg@merit.edu Thu Jun 13 15:52: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 PAA28208 for ; Thu, 13 Jun 2002 15:52:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF9E491339; Thu, 13 Jun 2002 15:52:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BABAF9133A; Thu, 13 Jun 2002 15:52: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 9AE9A91339 for ; Thu, 13 Jun 2002 15:52:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 157DF5DDE8; Thu, 13 Jun 2002 15:52:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id DE0555DDBE for ; Thu, 13 Jun 2002 15:52:34 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DJqZT15196; Thu, 13 Jun 2002 15:52:36 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 15:52:36 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5E9@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Daniel Warren" , "'Bernard Aboba'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's Date: Thu, 13 Jun 2002 15:52:31 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-aaa-wg@merit.edu Precedence: bulk I think a point Randy made is being missed -- one I've heard before in the SIP arena. It's OK for VSAs to be marked mandatory, and it's OK for the receiver to send back an error indicating a VSC or VSA was not understood. What is then required is that, under these circumstances, the message originator is able to fall back to an operation where it does not use the VSA or VSC concerned. Yes, this means loss of service, but that is the gist of what Randy said would be required. -----Original Message----- From: Warren, Daniel [MDN05:EP10:EXCH] Sent: Thursday, June 13, 2002 10:30 AM To: 'Bernard Aboba' Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's > > Case 1 - Extending an IETF defined command by adding a Vendor Specific AVP > > In this case, the AVP has to be optional. Setting the Mandatory AVP bit > > would mean that all implementations would have to support this AVP in the > > command and so that would no longer be vendor specific, but would rather be > > a requirement. > > Why is this true? Vendor extensions relating to security need to be > mandatory or security is compromised. We saw this with RADIUS when vendors > added support for explicit filters, and NASes that didn't understand them > did a silent discard, resulting in networks being provisioned without > filters, with no error message to the AAA server. An example. Vendor A implements a Vendor Specific AVP. For whatever reason, this AVP gets sent to a peer made by Vendor B, which does not understand or recognise this AVP (because it is identified with Vendor A's vendor-id). For interoperability, Vendor A's AVP must not affect the successful undertanding of the command by Vendor B's equipment. Therefore, the AVP must be optional so that Vendor B's equipment is allowed to ignore it - if it were mandatory, Vendor B (and any other vendor's) equipment would have to be able to understand the AVP else the command would fail. That means the AVP is no longer vendor specific, because every vendor has to implement it because it is a mandatory requirement. > > > Case 2 - Vendor defines a Vendor Specific Command > > Within this command, the vendor is able to set Mandatory AVP's. > No! Vendor Specific Commands are a last resort I agree! > , since they require new > code on the AAA server, whereas vendor-specific AVPs (mandatory or not) > can often be added to the dictionary. So the result of using a VSC instead > of a mandatory vendor-specific AVP is that only the vendor's Diameter > server can be used with their NAS. Not if the command is optional. Again, if vendor A's server has implemented a command that it uses towards vendor A's NAS and also towards vendor B's NAS as well, it will advertise that capability in the CER. Vendor A's NAS will respond with the command code confirming support of the VSC, whilst vendor B's NAS will not. The VSC is not allowed to affect interoperability, so Vendor A's server and Vendor B's NAS still have to be able to work without the VSC of vendor A. Therefore the VSC has to be optional. > > > That would > > indicate that if the Command is supported on an implementation, the AVP has > > to be present. However, the command as a whole has to be optional so that > > it does not violate interoperability with other vendor's implementations. > > I don't see how a legitimate VSC can be optional. If it truly represents a > new kind of service, then either the AAA supports that service or not. > However, I can see an unsolicited VSC sent from AAA server to NAS being > optional. For interoperability, operation has to be able to continue when VSC or VSAVP are ignored by the receiving node if that node does not understand them. Therefore they must be optional. > > > These two points seem obvious to me, but I think the discussions of the last > > few days have shown some confusion about what a vendor can and cannot > > reasonably define and implement in terms of extensions to Diameter. > > > > Fundamentally, the rule has to be that no peer is obliged to implement any > > vendor specific extension, be it an AVP, Command, or entire application. > > I don't agree with this interpretation - the spec allows (and even > encourages) use of vendor-specific AVPs instead of vendor-specific > commands and applications. VSAs can be mandatory. If a VSA is mandatory, then every vendor's equipment has to be able to receive it and understand it's meaning. If every vendor has to implement the VENDOR SPECIFIC AVP, then it isn't vendor specific anymore, it is vendor agnostic. The only other way I can conceive of making my point is to ask what the situation is with an AVP, marked as mandatory, which is defined in an IETF Diameter Application. If a server sends this to a NAS, the server must be able to expect the NAS to understand it. If the NAS doesn't understand the AVP, then because the AVP is essential to the operation (else it would not be marked as mandatory), the command would fail. Similarly, by allowing a VSA to be mandatory, the server must be able to expect the NAS to understand the VSA. If the NAS does not understand the VSA, again it has to fail the command, because if the VSA was not essential to the operation, it would not be mandatory. But to maintain interop, the NAS has to be able to complete the command without the VSA. Hence there is a contradiction in the logic. Mandatory implies understanding, but interop requires it to be ignored. You can't have both. From owner-aaa-wg@merit.edu Thu Jun 13 16:06: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 QAA28719 for ; Thu, 13 Jun 2002 16:06:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5DB229133A; Thu, 13 Jun 2002 16:06:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CAE79133B; Thu, 13 Jun 2002 16:06: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 1F5119133A for ; Thu, 13 Jun 2002 16:06:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FCEA5DDBE; Thu, 13 Jun 2002 16:06:53 -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 6DF725DDB1 for ; Thu, 13 Jun 2002 16:06:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17Ias0-0003g1-00; Thu, 13 Jun 2002 13:07:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tom-PT Taylor" Cc: "Daniel Warren" , "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's References: <4D79C746863DD51197690002A52CDA0001E8A5E9@zcard0kc.ca.nortel.com> Message-Id: Date: Thu, 13 Jun 2002 13:07:00 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I think a point Randy made is being missed -- one I've heard > before in the SIP arena. It's OK for VSAs to be marked > mandatory, and it's OK for the receiver to send back an error > indicating a VSC or VSA was not understood. What is then > required is that, under these circumstances, the message > originator is able to fall back to an operation where it does not > use the VSA or VSC concerned. Yes, this means loss of service, > but that is the gist of what Randy said would be required. the iesg was willing to eat this particular bit of dog food a few years back. while i can not promise it will meet their appetites today, it's worth a try. the point is that blame for failure MUST clearly be with the requestor of the non-ietf standard extension. and making this very clear, with no weasel words, just could squeak by. "do you do frobnitz?" "nope, sorry, i do not" "oops! sorry, did not mean to offend" randy From owner-aaa-wg@merit.edu Thu Jun 13 16:29: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 QAA29365 for ; Thu, 13 Jun 2002 16:29:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9CCC491201; Thu, 13 Jun 2002 16:29:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EA1D9133B; Thu, 13 Jun 2002 16:29: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 6B58A91201 for ; Thu, 13 Jun 2002 16:29:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C49E85DDE8; Thu, 13 Jun 2002 16:29:40 -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 EC2F35DDB1 for ; Thu, 13 Jun 2002 16:29:39 -0400 (EDT) Received: (qmail 30310 invoked by uid 500); 13 Jun 2002 20:29:49 -0000 Date: Thu, 13 Jun 2002 15:29:49 -0500 From: David Frascone To: Tom-PT Taylor Cc: Daniel Warren , "'Bernard Aboba'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Mandatory Vendor-specific AVP's Message-ID: <20020613202949.GM28565@newman.frascone.com> Mail-Followup-To: Tom-PT Taylor , Daniel Warren , 'Bernard Aboba' , aaa-wg@merit.edu References: <4D79C746863DD51197690002A52CDA0001E8A5E9@zcard0kc.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A5E9@zcard0kc.ca.nortel.com> X-encrypt-payload: no User-Agent: Mutt/1.5.1i Sender: owner-aaa-wg@merit.edu Precedence: bulk I think such a requirement is very reasonable. On Thursday, 13 Jun 2002, Tom-PT Taylor wrote: > I think a point Randy made is being missed -- one I've heard before in the > SIP arena. It's OK for VSAs to be marked mandatory, and it's OK for the > receiver to send back an error indicating a VSC or VSA was not understood. > What is then required is that, under these circumstances, the message > originator is able to fall back to an operation where it does not use the > VSA or VSC concerned. Yes, this means loss of service, but that is the gist > of what Randy said would be required. > > -----Original Message----- > From: Warren, Daniel [MDN05:EP10:EXCH] > Sent: Thursday, June 13, 2002 10:30 AM > To: 'Bernard Aboba' > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's > > > > > Case 1 - Extending an IETF defined command by adding a Vendor Specific > AVP > > > In this case, the AVP has to be optional. Setting the Mandatory AVP bit > > > > would mean that all implementations would have to support this AVP in > the > > > command and so that would no longer be vendor specific, but would rather > be > > > a requirement. > > > > Why is this true? Vendor extensions relating to security need to be > > mandatory or security is compromised. We saw this with RADIUS when vendors > > > added support for explicit filters, and NASes that didn't understand them > > did a silent discard, resulting in networks being provisioned without > > filters, with no error message to the AAA server. > An example. Vendor A implements a Vendor Specific AVP. For whatever > reason, this AVP gets sent to a peer made by Vendor B, which does not > understand or recognise this AVP (because it is identified with Vendor A's > vendor-id). For interoperability, Vendor A's AVP must not affect the > successful undertanding of the command by Vendor B's equipment. Therefore, > the AVP must be optional so that Vendor B's equipment is allowed to ignore > it - if it were mandatory, Vendor B (and any other vendor's) equipment would > have to be able to understand the AVP else the command would fail. That > means the AVP is no longer vendor specific, because every vendor has to > implement it because it is a mandatory requirement. > > > > > Case 2 - Vendor defines a Vendor Specific Command > > > Within this command, the vendor is able to set Mandatory AVP's. > > No! Vendor Specific Commands are a last resort > I agree! > > , since they require new > > code on the AAA server, whereas vendor-specific AVPs (mandatory or not) > > can often be added to the dictionary. So the result of using a VSC instead > > > of a mandatory vendor-specific AVP is that only the vendor's Diameter > > server can be used with their NAS. > Not if the command is optional. Again, if vendor A's server has implemented > a command that it uses towards vendor A's NAS and also towards vendor B's > NAS as well, it will advertise that capability in the CER. Vendor A's NAS > will respond with the command code confirming support of the VSC, whilst > vendor B's NAS will not. The VSC is not allowed to affect interoperability, > so Vendor A's server and Vendor B's NAS still have to be able to work > without the VSC of vendor A. Therefore the VSC has to be optional. > > > > > That would > > > indicate that if the Command is supported on an implementation, the AVP > has > > > to be present. However, the command as a whole has to be optional so > that > > > it does not violate interoperability with other vendor's > implementations. > > > > I don't see how a legitimate VSC can be optional. If it truly represents a > > > new kind of service, then either the AAA supports that service or not. > > However, I can see an unsolicited VSC sent from AAA server to NAS being > > optional. > For interoperability, operation has to be able to continue when VSC or VSAVP > are ignored by the receiving node if that node does not understand them. > Therefore they must be optional. > > > > > These two points seem obvious to me, but I think the discussions of the > last > > > few days have shown some confusion about what a vendor can and cannot > > > reasonably define and implement in terms of extensions to Diameter. > > > > > > > Fundamentally, the rule has to be that no peer is obliged to implement > any > > > vendor specific extension, be it an AVP, Command, or entire application. > > > > > I don't agree with this interpretation - the spec allows (and even > > encourages) use of vendor-specific AVPs instead of vendor-specific > > commands and applications. VSAs can be mandatory. > If a VSA is mandatory, then every vendor's equipment has to be able to > receive it and understand it's meaning. If every vendor has to implement > the VENDOR SPECIFIC AVP, then it isn't vendor specific anymore, it is vendor > agnostic. > The only other way I can conceive of making my point is to ask what the > situation is with an AVP, marked as mandatory, which is defined in an IETF > Diameter Application. If a server sends this to a NAS, the server must be > able to expect the NAS to understand it. If the NAS doesn't understand the > AVP, then because the AVP is essential to the operation (else it would not > be marked as mandatory), the command would fail. Similarly, by allowing a > VSA to be mandatory, the server must be able to expect the NAS to > understand the VSA. If the NAS does not understand the VSA, again it has to > fail the command, because if the VSA was not essential to the operation, it > would not be mandatory. But to maintain interop, the NAS has to be able to > complete the command without the VSA. Hence there is a contradiction in the > logic. Mandatory implies understanding, but interop requires it to be > ignored. You can't have both. > -- David Frascone Put the cat out? I didn't know it was burning! From owner-aaa-wg@merit.edu Thu Jun 13 19:25: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 TAA03817 for ; Thu, 13 Jun 2002 19:25:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 923E79133D; Thu, 13 Jun 2002 19:26:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F5509133E; Thu, 13 Jun 2002 19:26:10 -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 6A31F9133D for ; Thu, 13 Jun 2002 19:26:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E10A35DE7C; Thu, 13 Jun 2002 19:26:05 -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 751A15DDE7 for ; Thu, 13 Jun 2002 19:26:05 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5DMaL129389; Thu, 13 Jun 2002 15:36:21 -0700 Date: Thu, 13 Jun 2002 15:36:21 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: "Carolina Canales Valenzuela (ECE)" , , , Subject: RE: [AAA-WG]: Proposal: Resolution of Vendor Specific Commands Is sue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Since what exemplifies a Diameter application is the definition of "at least > one Command Code", it sure sounds like the hypothetical accounting server > better be able to handle anything; either that, or we redefine the term > "relay". Yes, I agree that this is what the hypothetical accounting server must be able to do to advertise the relay application. However, I'm saying that, unlike a relay, an accounting server can't actually fulfill that requirement. While a relay can forward commands it doesn't understand, an accounting server can't carry out command it doesn't understand, although it *can* write to disk Vendor-Specific AVPs it doesn't understand. From owner-aaa-wg@merit.edu Fri Jun 14 03:58: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 DAA22575 for ; Fri, 14 Jun 2002 03:58:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65C5E91231; Fri, 14 Jun 2002 03:58:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 277439128C; Fri, 14 Jun 2002 03:58: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 DC9C291231 for ; Fri, 14 Jun 2002 03:58:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 581285DE19; Fri, 14 Jun 2002 03:58:28 -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 A6F665DDA6 for ; Fri, 14 Jun 2002 03:58:27 -0400 (EDT) Received: from fmorn1dcode948i (manmsr.local.ipunplugged.com [213.88.134.212]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g5E7xFUg008070; Fri, 14 Jun 2002 09:59:15 +0200 From: "Fredrik Johansson" To: "David Frascone" , "Tom-PT Taylor" Cc: "Daniel Warren" , "'Bernard Aboba'" , Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's Date: Fri, 14 Jun 2002 09:59:03 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <20020613202949.GM28565@newman.frascone.com> X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit It's reasonable and isn't it something we have today. If a vendor A sends a Vendor specific AVP with the 'M'-bit marked to vendor B, vendor B either understands it and is happy or doesn't understand it and sends an error back and denies the service. In the latter case, Vendor A is then the one to blame and has the option to try to request the service without the AVP (ofcourse with a different service as result) or to give up. /fredrik > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > David Frascone > Sent: den 13 juni 2002 22:30 > To: Tom-PT Taylor > Cc: Daniel Warren; 'Bernard Aboba'; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Mandatory Vendor-specific AVP's > > > I think such a requirement is very reasonable. > > On Thursday, 13 Jun 2002, Tom-PT Taylor wrote: > > I think a point Randy made is being missed -- one I've heard > before in the > > SIP arena. It's OK for VSAs to be marked mandatory, and it's OK for the > > receiver to send back an error indicating a VSC or VSA was not > understood. > > What is then required is that, under these circumstances, the message > > originator is able to fall back to an operation where it does > not use the > > VSA or VSC concerned. Yes, this means loss of service, but > that is the gist > > of what Randy said would be required. > > > > -----Original Message----- > > From: Warren, Daniel [MDN05:EP10:EXCH] > > Sent: Thursday, June 13, 2002 10:30 AM > > To: 'Bernard Aboba' > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's > > > > > > > > Case 1 - Extending an IETF defined command by adding a > Vendor Specific > > AVP > > > > In this case, the AVP has to be optional. Setting the > Mandatory AVP bit > > > > > > would mean that all implementations would have to support > this AVP in > > the > > > > command and so that would no longer be vendor specific, but > would rather > > be > > > > a requirement. > > > > > > Why is this true? Vendor extensions relating to security need to be > > > mandatory or security is compromised. We saw this with RADIUS > when vendors > > > > > added support for explicit filters, and NASes that didn't > understand them > > > did a silent discard, resulting in networks being provisioned without > > > filters, with no error message to the AAA server. > > An example. Vendor A implements a Vendor Specific AVP. For whatever > > reason, this AVP gets sent to a peer made by Vendor B, which does not > > understand or recognise this AVP (because it is identified with > Vendor A's > > vendor-id). For interoperability, Vendor A's AVP must not affect the > > successful undertanding of the command by Vendor B's equipment. > Therefore, > > the AVP must be optional so that Vendor B's equipment is > allowed to ignore > > it - if it were mandatory, Vendor B (and any other vendor's) > equipment would > > have to be able to understand the AVP else the command would fail. That > > means the AVP is no longer vendor specific, because every vendor has to > > implement it because it is a mandatory requirement. > > > > > > > Case 2 - Vendor defines a Vendor Specific Command > > > > Within this command, the vendor is able to set Mandatory AVP's. > > > No! Vendor Specific Commands are a last resort > > I agree! > > > , since they require new > > > code on the AAA server, whereas vendor-specific AVPs > (mandatory or not) > > > can often be added to the dictionary. So the result of using > a VSC instead > > > > > of a mandatory vendor-specific AVP is that only the vendor's Diameter > > > server can be used with their NAS. > > Not if the command is optional. Again, if vendor A's server > has implemented > > a command that it uses towards vendor A's NAS and also towards > vendor B's > > NAS as well, it will advertise that capability in the CER. > Vendor A's NAS > > will respond with the command code confirming support of the VSC, whilst > > vendor B's NAS will not. The VSC is not allowed to affect > interoperability, > > so Vendor A's server and Vendor B's NAS still have to be able to work > > without the VSC of vendor A. Therefore the VSC has to be optional. > > > > > > > That would > > > > indicate that if the Command is supported on an > implementation, the AVP > > has > > > > to be present. However, the command as a whole has to be > optional so > > that > > > > it does not violate interoperability with other vendor's > > implementations. > > > > > > I don't see how a legitimate VSC can be optional. If it truly > represents a > > > > > new kind of service, then either the AAA supports that > service or not. > > > However, I can see an unsolicited VSC sent from AAA server to > NAS being > > > optional. > > For interoperability, operation has to be able to continue when > VSC or VSAVP > > are ignored by the receiving node if that node does not understand them. > > Therefore they must be optional. > > > > > > > These two points seem obvious to me, but I think the > discussions of the > > last > > > > few days have shown some confusion about what a vendor can > and cannot > > > > reasonably define and implement in terms of extensions to Diameter. > > > > > > > > > > Fundamentally, the rule has to be that no peer is obliged > to implement > > any > > > > vendor specific extension, be it an AVP, Command, or entire > application. > > > > > > > > I don't agree with this interpretation - the spec allows (and even > > > encourages) use of vendor-specific AVPs instead of vendor-specific > > > commands and applications. VSAs can be mandatory. > > If a VSA is mandatory, then every vendor's equipment has to be able to > > receive it and understand it's meaning. If every vendor has to > implement > > the VENDOR SPECIFIC AVP, then it isn't vendor specific anymore, > it is vendor > > agnostic. > > The only other way I can conceive of making my point is to ask what the > > situation is with an AVP, marked as mandatory, which is defined > in an IETF > > Diameter Application. If a server sends this to a NAS, the > server must be > > able to expect the NAS to understand it. If the NAS doesn't > understand the > > AVP, then because the AVP is essential to the operation (else > it would not > > be marked as mandatory), the command would fail. Similarly, by > allowing a > > VSA to be mandatory, the server must be able to expect the NAS to > > understand the VSA. If the NAS does not understand the VSA, > again it has to > > fail the command, because if the VSA was not essential to the > operation, it > > would not be mandatory. But to maintain interop, the NAS has > to be able to > > complete the command without the VSA. Hence there is a > contradiction in the > > logic. Mandatory implies understanding, but interop requires it to be > > ignored. You can't have both. > > > > -- > David Frascone > > Put the cat out? I didn't know it was burning! From owner-aaa-wg@merit.edu Fri Jun 14 04:06:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22733 for ; Fri, 14 Jun 2002 04:06:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 160089128C; Fri, 14 Jun 2002 04:06:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D192191320; Fri, 14 Jun 2002 04:06: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 AB4D09128C for ; Fri, 14 Jun 2002 04:06:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B5E85DDA6; Fri, 14 Jun 2002 04:06:48 -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 1F5BE5DE19 for ; Fri, 14 Jun 2002 04:06:46 -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 g5E85Zd19188 for ; Fri, 14 Jun 2002 11:05:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Jun 2002 11:06:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 11:06:53 +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]: Decision time was: Mandatory Vendor-specific AVP's Date: Fri, 14 Jun 2002 11:06:52 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65454@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Mandatory Vendor-specific AVP's Thread-Index: AcITeVhUhg+lWZSSRTyBdyGvFHzbmQAAIiwA X-Priority: 1 Importance: high From: To: , , Cc: , , X-OriginalArrivalTime: 14 Jun 2002 08:06:53.0258 (UTC) FILETIME=[7198EAA0:01C2137A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA22733 Hi all, > It's reasonable and isn't it something we have today. > > If a vendor A sends a Vendor specific AVP with the 'M'-bit marked to vendor > B, vendor B either understands it and is happy or doesn't understand it and > sends an error back and denies the service. In the latter case, Vendor A is > then the one to blame and has the option to try to request the service > without the AVP (ofcourse with a different service as result) > or to give up. I think we are arguing about the wrong thing. There is concern by the IESG that vendor extensions may cause interoperability problems. I don't think that anyone desires interop problems. The questions is, do we have the information in the Base Spec to overcome these concerns. The 3 possible answers are: 1) No we don't 2) Yes we do, but it is not stated well enough 3) Yes we do and anyone who read the document would know it. I suggest we are at point 2). I do think Randy has read the document, and I think the burden of proof is on us to ensure the document is clear. Therefore, I suggested improved text yesterday. This text is included at the bottom of the mail. Please comment. John ==== 1.2 Approach to Extensibility The Diameter protocol is designed to be extensible. The extensibility includes: - Defining new AVP values. - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures Reuse of existing AVP values, AVPs, applications and command codes are is strongly recommended. Reuse simplifies standardization effort, implentation effort and avoids potential interoperability issues. 1.2.1 Standardized Extensions Versus Vendor-Specific Extensions Diameter can be extended by standards track documents in the IETF. The benefit of this is that the extensions become Internet standards, allowing for wider possible deployment and higher assurance of interoperability. It is strongly recommended that extensions to Diameter be made by standards-track RFCs. Vendor-specific extensions are allowed, and MUST be registered through IANA (see section 11.2). However, vendor-specific extensions MUST NOT harm interoperability of standards-based Diameter implementations. Vendor-specific commands MUST NOT be used where an existing command plus a vendor-specific AVPs would the same objective. If this basic precept is followed, then most interoperability problems are solved. Vendor-specific commands MUST NOT be sent in response to standard commands. Unsolicited VSCs sent from a AAA server to a NAS are to be treated as non-mandatory. All vendor-specific Diameter commands require Informational RFCs documenting the command unless for Private Use as described in Section 11.2.1. As a general rule, any errors involving Vendor-specific AVP marked with the 'M' bit are considered the fault of the side setting the 'M' bit (see Section 4.1). 1.2.2 Defining New AVP Values New applications should attempt to reuse AVPs defined in existing applications when possible, as opposed to creating new AVPs. For AVPs of type Enumerated, it is possible the application requires a new value to communicate some service-specific information. In order to allocate a new AVP value, a request MUST be sent to IANA [IANA], with a detailed explanation of the value and document on the value. 1.2.3 Creating New AVPs When no existing AVP can be used appropriately to communicate some service-specific information, a new AVP should be created. The new AVP being defined MUST follow one of the types listed in section 4.3. In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is highly recommended that a Grouped AVP be used (see Section 4.5). In order to create a new AVP, a request MUST be sent to IANA, with a detailed explanation of the AVP, its type and possible values. Furthermore, the request MUST include the commands that would make use of the AVP. 1.2.4 Creating New Authentication Applications Should a new application require Diameter support, but it cannot fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include: - Requiring a whole different set of mandatory AVPs to a command - Requiring a command that has a different number of round trips to satisfy a request (e.g. application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete). - The method used to authenticate the user is drastically different from any existing application, and the authentication information cannot be carried within the AVPs defined in the application. Note that the creation of a new application should be viewed as a last resort. New Diameter applications MUST define at least one Command Code, the expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY also define new AVPs. If the Diameter application has any accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see section 9.3). When possible, a new Diameter application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter application specification MUST have an IANA assigned Application Identifier (see section 2.4). 1.2.5 Creating New Accounting Applications Services that have an Application Identifier MUST use the same identifier also to identify the service when Diameter accounting is used. There are services that only require the use of Diameter accounting. Such services need to define the service specific AVPs that must be carried in the Accounting-Request/Answer messages, but do not need to define command codes. Application Identifiers are, however, still required for accounting due to the Diameter capability discovery process. Every accounting application MUST have either an IANA allocated Application Identifier, or a vendor specific Application Identifier. Note that the creation of a new application should be viewed as a last resort and should be used only when Vendor-Specific AVPs are insufficient. In most cases, reusing an existing Application ID with Vendor-Specific AVPs should work. For example, many accounting servers are set up to write AVPs to disk, so they can handle even mandatory vendor-specific AVPs that they don't understand. This is why "disk writing" accounting servers should advertise themselves as "Relays" that can handle any Application ID, including Vendor-Specific. When possible, a new Diameter accounting application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter accounting application specification MUST have an IANA assigned Application Identifier (see section 2.4). 1.2.6 Application Authentication Procedures When possible, applications SHOULD be designed such that new authentication methods MAY be added without requiring changes to the application. This MAY require that new AVP values be assigned to represent the new authentication transform, or any other scheme that produces similar results. When possible, authentication frameworks, such as Extensible Authentication Protocol [EAP], SHOULD be used. From owner-aaa-wg@merit.edu Fri Jun 14 09: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 JAA28953 for ; Fri, 14 Jun 2002 09:35:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83BCC91342; Fri, 14 Jun 2002 09:35:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AA9591343; Fri, 14 Jun 2002 09:35: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 393A391342 for ; Fri, 14 Jun 2002 09:35:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C35745DE6F; Fri, 14 Jun 2002 09:35:48 -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 EB2455DDB8 for ; Fri, 14 Jun 2002 09:35:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5ECjm612455; Fri, 14 Jun 2002 05:45:48 -0700 Date: Fri, 14 Jun 2002 05:45:48 -0700 (PDT) From: Bernard Aboba To: Fredrik Johansson Cc: David Frascone , Tom-PT Taylor , Daniel Warren , Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's 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 agree that this is worthwhile, and it is something that is possible in Diameter that was not possible in RADIUS (since RADIUS had no error messages). It preserves interoperability, and yet also enables extensibility. On Fri, 14 Jun 2002, Fredrik Johansson wrote: > It's reasonable and isn't it something we have today. > > If a vendor A sends a Vendor specific AVP with the 'M'-bit marked to vendor > B, vendor B either understands it and is happy or doesn't understand it and > sends an error back and denies the service. In the latter case, Vendor A is > then the one to blame and has the option to try to request the service > without the AVP (ofcourse with a different service as result) or to give up. > > /fredrik > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > David Frascone > > Sent: den 13 juni 2002 22:30 > > To: Tom-PT Taylor > > Cc: Daniel Warren; 'Bernard Aboba'; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Mandatory Vendor-specific AVP's > > > > > > I think such a requirement is very reasonable. > > > > On Thursday, 13 Jun 2002, Tom-PT Taylor wrote: > > > I think a point Randy made is being missed -- one I've heard > > before in the > > > SIP arena. It's OK for VSAs to be marked mandatory, and it's OK for the > > > receiver to send back an error indicating a VSC or VSA was not > > understood. > > > What is then required is that, under these circumstances, the message > > > originator is able to fall back to an operation where it does > > not use the > > > VSA or VSC concerned. Yes, this means loss of service, but > > that is the gist > > > of what Randy said would be required. > > > > > > -----Original Message----- > > > From: Warren, Daniel [MDN05:EP10:EXCH] > > > Sent: Thursday, June 13, 2002 10:30 AM > > > To: 'Bernard Aboba' > > > Cc: aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: Mandatory Vendor-specific AVP's > > > > > > > > > > > Case 1 - Extending an IETF defined command by adding a > > Vendor Specific > > > AVP > > > > > In this case, the AVP has to be optional. Setting the > > Mandatory AVP bit > > > > > > > > would mean that all implementations would have to support > > this AVP in > > > the > > > > > command and so that would no longer be vendor specific, but > > would rather > > > be > > > > > a requirement. > > > > > > > > Why is this true? Vendor extensions relating to security need to be > > > > mandatory or security is compromised. We saw this with RADIUS > > when vendors > > > > > > > added support for explicit filters, and NASes that didn't > > understand them > > > > did a silent discard, resulting in networks being provisioned without > > > > filters, with no error message to the AAA server. > > > An example. Vendor A implements a Vendor Specific AVP. For whatever > > > reason, this AVP gets sent to a peer made by Vendor B, which does not > > > understand or recognise this AVP (because it is identified with > > Vendor A's > > > vendor-id). For interoperability, Vendor A's AVP must not affect the > > > successful undertanding of the command by Vendor B's equipment. > > Therefore, > > > the AVP must be optional so that Vendor B's equipment is > > allowed to ignore > > > it - if it were mandatory, Vendor B (and any other vendor's) > > equipment would > > > have to be able to understand the AVP else the command would fail. That > > > means the AVP is no longer vendor specific, because every vendor has to > > > implement it because it is a mandatory requirement. > > > > > > > > > Case 2 - Vendor defines a Vendor Specific Command > > > > > Within this command, the vendor is able to set Mandatory AVP's. > > > > No! Vendor Specific Commands are a last resort > > > I agree! > > > > , since they require new > > > > code on the AAA server, whereas vendor-specific AVPs > > (mandatory or not) > > > > can often be added to the dictionary. So the result of using > > a VSC instead > > > > > > > of a mandatory vendor-specific AVP is that only the vendor's Diameter > > > > server can be used with their NAS. > > > Not if the command is optional. Again, if vendor A's server > > has implemented > > > a command that it uses towards vendor A's NAS and also towards > > vendor B's > > > NAS as well, it will advertise that capability in the CER. > > Vendor A's NAS > > > will respond with the command code confirming support of the VSC, whilst > > > vendor B's NAS will not. The VSC is not allowed to affect > > interoperability, > > > so Vendor A's server and Vendor B's NAS still have to be able to work > > > without the VSC of vendor A. Therefore the VSC has to be optional. > > > > > > > > > That would > > > > > indicate that if the Command is supported on an > > implementation, the AVP > > > has > > > > > to be present. However, the command as a whole has to be > > optional so > > > that > > > > > it does not violate interoperability with other vendor's > > > implementations. > > > > > > > > I don't see how a legitimate VSC can be optional. If it truly > > represents a > > > > > > > new kind of service, then either the AAA supports that > > service or not. > > > > However, I can see an unsolicited VSC sent from AAA server to > > NAS being > > > > optional. > > > For interoperability, operation has to be able to continue when > > VSC or VSAVP > > > are ignored by the receiving node if that node does not understand them. > > > Therefore they must be optional. > > > > > > > > > These two points seem obvious to me, but I think the > > discussions of the > > > last > > > > > few days have shown some confusion about what a vendor can > > and cannot > > > > > reasonably define and implement in terms of extensions to Diameter. > > > > > > > > > > > > > Fundamentally, the rule has to be that no peer is obliged > > to implement > > > any > > > > > vendor specific extension, be it an AVP, Command, or entire > > application. > > > > > > > > > > > I don't agree with this interpretation - the spec allows (and even > > > > encourages) use of vendor-specific AVPs instead of vendor-specific > > > > commands and applications. VSAs can be mandatory. > > > If a VSA is mandatory, then every vendor's equipment has to be able to > > > receive it and understand it's meaning. If every vendor has to > > implement > > > the VENDOR SPECIFIC AVP, then it isn't vendor specific anymore, > > it is vendor > > > agnostic. > > > The only other way I can conceive of making my point is to ask what the > > > situation is with an AVP, marked as mandatory, which is defined > > in an IETF > > > Diameter Application. If a server sends this to a NAS, the > > server must be > > > able to expect the NAS to understand it. If the NAS doesn't > > understand the > > > AVP, then because the AVP is essential to the operation (else > > it would not > > > be marked as mandatory), the command would fail. Similarly, by > > allowing a > > > VSA to be mandatory, the server must be able to expect the NAS to > > > understand the VSA. If the NAS does not understand the VSA, > > again it has to > > > fail the command, because if the VSA was not essential to the > > operation, it > > > would not be mandatory. But to maintain interop, the NAS has > > to be able to > > > complete the command without the VSA. Hence there is a > > contradiction in the > > > logic. Mandatory implies understanding, but interop requires it to be > > > ignored. You can't have both. > > > > > > > -- > > David Frascone > > > > Put the cat out? I didn't know it was burning! > From owner-aaa-wg@merit.edu Fri Jun 14 10:00: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 KAA29926 for ; Fri, 14 Jun 2002 10:00:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A844E91216; Fri, 14 Jun 2002 10:00:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E12B91344; Fri, 14 Jun 2002 10:00: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 5BAFD91216 for ; Fri, 14 Jun 2002 10:00:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E24135DDBE; Fri, 14 Jun 2002 10:00:43 -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 E78E15DDA6 for ; Fri, 14 Jun 2002 10:00:42 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5EDAkG13819; Fri, 14 Jun 2002 06:10:46 -0700 Date: Fri, 14 Jun 2002 06:10:46 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: fredrik.johansson@ipunplugged.com, , , , Subject: [AAA-WG]: Re: Decision time was: Mandatory Vendor-specific AVP's In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65454@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 > 1.2 Approach to Extensibility > > The Diameter protocol is designed to be extensible. The extensibility > includes: > > - Defining new AVP values. > - Creating new AVPs > - Creating new authentication/authorization applications > - Creating new accounting applications > - Application authentication procedures > > Reuse of existing AVP values, AVPs, applications and command codes are > is strongly recommended. Reuse simplifies standardization effort, > implentation effort and avoids potential interoperability issues. change "are is strongly recommended" to "is RECOMMENDED." change "implentation" to "implementation" > > 1.2.1 Standardized Extensions Versus Vendor-Specific Extensions > > Diameter can be extended by standards track documents in the IETF. > The benefit of this is that the extensions become Internet standards, > allowing for wider possible deployment and higher assurance of > interoperability. It is strongly recommended that extensions to > Diameter be made by standards-track RFCs. > > Vendor-specific extensions are allowed, and MUST be registered through > IANA (see section 11.2). However, vendor-specific extensions MUST NOT > harm interoperability of standards-based Diameter implementations. Don't understand meaning of "extensions" here. Is this VSCs? VSAs? Registration through IANA can't be mandatory for private extensions and the sentence above seems to contradict text below. Recommend deleting the above paragraph. > > Vendor-specific commands MUST NOT be used where an existing command plus a > vendor-specific AVPs would the same objective. If this basic precept is change "would the same" to "would meet the same" > followed, then most interoperability problems are solved. change "are solved" to "can be avoided". > Vendor-specific commands MUST NOT be sent in response to standard > commands. Unsolicited VSCs > sent from a AAA server to a NAS are to be treated as non-mandatory. All Change this to: "Vendor-specific commands MUST NOT be sent except where they are known to be supported as a result of capabilities negotiation between the peers. Even where they are supported, Vendor-Specific commands MUST NOT be sent in response to standard commands." > vendor-specific Diameter commands require Informational RFCs documenting > the command unless for Private Use as described in Section 11.2.1. > > As a general rule, any errors involving Vendor-specific AVP marked with > the 'M' bit are considered the fault of the side setting the 'M' bit (see > Section 4.1). Add: "A Diameter peer sending a command containing Vendor-Specific AVPs marked with the 'M' bit, and receiving indication from its peer that this AVP is not supported, SHOULD retry the command with the Vendor-Specific AVP removed, if this is feasible. This enables interoperability for standard applications extended with Vendor-Specific AVPs marked with the 'M' bit." > 1.2.2 Defining New AVP Values > > New applications should attempt to reuse AVPs defined in existing > applications when possible, as opposed to creating new AVPs. For AVPs > of type Enumerated, it is possible the application requires a new > value to communicate some service-specific information. > > In order to allocate a new AVP value, a request MUST be sent to IANA > [IANA], with a detailed explanation of the value and document on the > value. > > 1.2.3 Creating New AVPs > > When no existing AVP can be used appropriately to communicate some > service-specific information, a new AVP should be created. The new > AVP being defined MUST follow one of the types listed in section 4.3. > In the event that a logical grouping of AVPs is necessary, and > multiple "groups" are possible in a given command, it is highly > recommended that a Grouped AVP be used (see Section 4.5). > > In order to create a new AVP, a request MUST be sent to IANA, with a > detailed explanation of the AVP, its type and possible values. > Furthermore, the request MUST include the commands that would make > use of the AVP. > > 1.2.4 Creating New Authentication Applications > > Should a new application require Diameter support, but it cannot fit > within an existing application without requiring major changes to the > specification, it may be desirable to create a new Diameter > application. Major changes to an application include: Add "Another reason to create a new Diameter application is if an extension cannot be implemented merely by adding AVPs to the dictionary, requiring new code to be implemented on both both Diameter peers." > > - Requiring a whole different set of mandatory AVPs to a command Not clear whether this means "AVPs marked with the 'M' bit" or "AVPs required to be included within the command." I don't believe that a new command is required just if some AVPs marked with the 'M' bit are added to a command. > - Requiring a command that has a different number of round trips > to satisfy a request (e.g. application foo has a command that > requires one round trip, but new application bar has a command > that requires two round trips to complete). > - The method used to authenticate the user is drastically > different from any existing application, and the authentication > information cannot be carried within the AVPs defined in the > application. Don't agree that this should require a new command. For example, why should a NAS adding support for a new PPP authentication method require an entirely new NASREQ application? This is particularly true since we recommend the opposite and discuss use of EAP as an alternative later in the section. Recommend deletion. > Note that the creation of a new application should be viewed as a > last resort. > > New Diameter applications MUST define at least one Command Code, the > expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY > also define new AVPs. If the Diameter application has any accounting > requirements, it MUST also specify the AVPs that are to be present in > the Diameter Accounting messages (see section 9.3). > > When possible, a new Diameter application SHOULD attempt to re-use > any existing Diameter AVP, in order to reduce the possibility of > having multiple AVPs that carry similar information. > > Every Diameter application specification MUST have an IANA assigned > Application Identifier (see section 2.4). > > 1.2.5 Creating New Accounting Applications > > Services that have an Application Identifier MUST use the same > identifier also to identify the service when Diameter accounting is > used. > > There are services that only require the use of Diameter accounting. > Such services need to define the service specific AVPs that must be > carried in the Accounting-Request/Answer messages, but do not need to > define command codes. Application Identifiers are, however, still > required for accounting due to the Diameter capability discovery This might create some interoperability problems as discussed below. > process. Every accounting application MUST have either an IANA > allocated Application Identifier, or a vendor specific Application > Identifier. > > Note that the creation of a new application should be viewed as a > last resort and should be used only when Vendor-Specific AVPs are > insufficient. In most cases, reusing an existing Application ID with > Vendor-Specific AVPs should work. For example, many accounting > servers are set up to write AVPs to disk, so they can handle even > mandatory vendor-specific AVPs that they don't understand. Change "mandatory vendor-specific AVPs that they don't understand" to "even Vendor-Specific AVPs marked with the 'M' bit that are unsupported." > > This is why "disk writing" accounting servers should advertise > themselves as "Relays" that can handle any Application ID, including > Vendor-Specific. Recommend adding: "Note that even when an accounting server advertises the "Relay" application it cannot be assumed it can handle unsupported Vendor-Specific Commands. For example, while an accounting server can handle Vendor-Specific AVPs within an ACA by writing them to disk, it cannot assume that a Vendor-Specific Command is equivalent to an ACA, and carry out the same operation." > When possible, a new Diameter accounting application SHOULD attempt > to re-use any existing Diameter AVP, in order to reduce the > possibility of having multiple AVPs that carry similar information. > > Every Diameter accounting application specification MUST have an IANA > assigned Application Identifier (see section 2.4). > > 1.2.6 Application Authentication Procedures > > When possible, applications SHOULD be designed such that new > authentication methods MAY be added without requiring changes to the > application. Note that this contradicts earlier text which was requested to be removed. > This MAY require that new AVP values be assigned to > represent the new authentication transform, or any other scheme that > produces similar results. When possible, authentication frameworks, > such as Extensible Authentication Protocol [EAP], SHOULD be used. From owner-aaa-wg@merit.edu Fri Jun 14 10:04: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 KAA00111 for ; Fri, 14 Jun 2002 10:04:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 04D5091344; Fri, 14 Jun 2002 10:05:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7BE891345; Fri, 14 Jun 2002 10:05:02 -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 89E1091344 for ; Fri, 14 Jun 2002 10:05:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BB365DDBE; Fri, 14 Jun 2002 10:04:58 -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 7DCB35DDA6 for ; Fri, 14 Jun 2002 10:04:57 -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 g5EE3ld10961 for ; Fri, 14 Jun 2002 17:03:48 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Jun 2002 17:05:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 17:05: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: [AAA-WG]: RE: Decision time was: Mandatory Vendor-specific AVP's Date: Fri, 14 Jun 2002 17:05:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65464@esebe004.NOE.Nokia.com> Thread-Topic: Decision time was: Mandatory Vendor-specific AVP's Thread-Index: AcITq+LNQWACPkCIQ8mtVTAaNZicAQAAIcyw From: To: Cc: , , , , X-OriginalArrivalTime: 14 Jun 2002 14:05:06.0194 (UTC) FILETIME=[7C62AF20:01C213AC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA00111 Hi, I can update the text. If Randy thinks this will be sufficient for the IESG, I will update the draft & publish it. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 14 June, 2002 16:11 > To: Loughney John (NRC/Helsinki) > Cc: fredrik.johansson@ipunplugged.com; dave@frascone.com; > taylor@nortelnetworks.com; dlwarren@nortelnetworks.com; > aaa-wg@merit.edu > Subject: Re: Decision time was: Mandatory Vendor-specific AVP's > > > > 1.2 Approach to Extensibility > > > > The Diameter protocol is designed to be extensible. The > extensibility > > includes: > > > > - Defining new AVP values. > > - Creating new AVPs > > - Creating new authentication/authorization applications > > - Creating new accounting applications > > - Application authentication procedures > > > > Reuse of existing AVP values, AVPs, applications and > command codes are > > is strongly recommended. Reuse simplifies > standardization effort, > > implentation effort and avoids potential interoperability issues. > > change "are is strongly recommended" to "is RECOMMENDED." > change "implentation" to "implementation" > > > > > 1.2.1 Standardized Extensions Versus Vendor-Specific Extensions > > > > Diameter can be extended by standards track documents in > the IETF. > > The benefit of this is that the extensions become > Internet standards, > > allowing for wider possible deployment and higher assurance of > > interoperability. It is strongly recommended that extensions to > > Diameter be made by standards-track RFCs. > > > > Vendor-specific extensions are allowed, and MUST be > registered through > > IANA (see section 11.2). However, vendor-specific > extensions MUST NOT > > harm interoperability of standards-based Diameter > implementations. > > Don't understand meaning of "extensions" here. Is this VSCs? VSAs? > Registration through IANA can't be mandatory for private > extensions and > the sentence above seems to contradict text below. Recommend > deleting the > above paragraph. > > > > > Vendor-specific commands MUST NOT be used where an > existing command plus a > > vendor-specific AVPs would the same objective. If this > basic precept is > > change "would the same" to "would meet the same" > > > followed, then most interoperability problems are solved. > > change "are solved" to "can be avoided". > > > Vendor-specific commands MUST NOT be sent in response to standard > > commands. Unsolicited VSCs > > sent from a AAA server to a NAS are to be treated as > non-mandatory. All > > Change this to: > > "Vendor-specific commands MUST NOT be sent except where they > are known to > be supported as a result of capabilities negotiation between > the peers. > Even where they are supported, Vendor-Specific commands MUST > NOT be sent > in response to standard commands." > > > vendor-specific Diameter commands require Informational > RFCs documenting > > the command unless for Private Use as described in > Section 11.2.1. > > > > As a general rule, any errors involving Vendor-specific > AVP marked with > > the 'M' bit are considered the fault of the side setting > the 'M' bit (see > > Section 4.1). > > Add: > > "A Diameter peer sending a command containing Vendor-Specific > AVPs marked > with the 'M' bit, and receiving indication from its peer that > this AVP is > not supported, SHOULD retry the command with the Vendor-Specific AVP > removed, if this is feasible. This enables interoperability > for standard > applications extended with Vendor-Specific AVPs marked with > the 'M' bit." > > > 1.2.2 Defining New AVP Values > > > > New applications should attempt to reuse AVPs defined in existing > > applications when possible, as opposed to creating new > AVPs. For AVPs > > of type Enumerated, it is possible the application requires a new > > value to communicate some service-specific information. > > > > In order to allocate a new AVP value, a request MUST be > sent to IANA > > [IANA], with a detailed explanation of the value and > document on the > > value. > > > > 1.2.3 Creating New AVPs > > > > When no existing AVP can be used appropriately to > communicate some > > service-specific information, a new AVP should be > created. The new > > AVP being defined MUST follow one of the types listed in > section 4.3. > > In the event that a logical grouping of AVPs is necessary, and > > multiple "groups" are possible in a given command, it is highly > > recommended that a Grouped AVP be used (see Section 4.5). > > > > In order to create a new AVP, a request MUST be sent to > IANA, with a > > detailed explanation of the AVP, its type and possible values. > > Furthermore, the request MUST include the commands that > would make > > use of the AVP. > > > > 1.2.4 Creating New Authentication Applications > > > > Should a new application require Diameter support, but > it cannot fit > > within an existing application without requiring major > changes to the > > specification, it may be desirable to create a new Diameter > > application. Major changes to an application include: > > Add "Another reason to create a new Diameter application is if an > extension cannot be implemented merely by adding AVPs to the > dictionary, > requiring new code to be implemented on both both Diameter peers." > > > > > - Requiring a whole different set of mandatory AVPs > to a command > > Not clear whether this means "AVPs marked with the 'M' bit" or "AVPs > required to be included within the command." I don't believe > that a new > command is required just if some AVPs marked with the 'M' bit > are added to > a command. > > > - Requiring a command that has a different number of > round trips > > to satisfy a request (e.g. application foo has a > command that > > requires one round trip, but new application bar > has a command > > that requires two round trips to complete). > > - The method used to authenticate the user is drastically > > different from any existing application, and the > authentication > > information cannot be carried within the AVPs defined in the > > application. > > Don't agree that this should require a new command. For example, why > should a NAS adding support for a new PPP authentication > method require an > entirely new NASREQ application? This is particularly true since we > recommend the opposite and discuss use of EAP as an > alternative later in > the section. Recommend deletion. > > > Note that the creation of a new application should be viewed as a > > last resort. > > > > New Diameter applications MUST define at least one > Command Code, the > > expected AVPs in an ABNF [ABNF] grammar (see section > 3.2), and MAY > > also define new AVPs. If the Diameter application has > any accounting > > requirements, it MUST also specify the AVPs that are to > be present in > > the Diameter Accounting messages (see section 9.3). > > > > When possible, a new Diameter application SHOULD attempt > to re-use > > any existing Diameter AVP, in order to reduce the possibility of > > having multiple AVPs that carry similar information. > > > > Every Diameter application specification MUST have an > IANA assigned > > Application Identifier (see section 2.4). > > > > 1.2.5 Creating New Accounting Applications > > > > Services that have an Application Identifier MUST use the same > > identifier also to identify the service when Diameter > accounting is > > used. > > > > There are services that only require the use of Diameter > accounting. > > Such services need to define the service specific AVPs > that must be > > carried in the Accounting-Request/Answer messages, but > do not need to > > define command codes. Application Identifiers are, however, still > > required for accounting due to the Diameter capability discovery > > This might create some interoperability problems as discussed below. > > > process. Every accounting application MUST have either an IANA > > allocated Application Identifier, or a vendor specific > Application > > Identifier. > > > > Note that the creation of a new application should be viewed as a > > last resort and should be used only when Vendor-Specific AVPs are > > insufficient. In most cases, reusing an existing > Application ID with > > Vendor-Specific AVPs should work. For example, many accounting > > servers are set up to write AVPs to disk, so they can handle even > > mandatory vendor-specific AVPs that they don't understand. > > Change "mandatory vendor-specific AVPs that they don't understand" to > "even Vendor-Specific AVPs marked with the 'M' bit that are > unsupported." > > > > > This is why "disk writing" accounting servers should advertise > > themselves as "Relays" that can handle any Application > ID, including > > Vendor-Specific. > > Recommend adding: > > "Note that even when an accounting server advertises the "Relay" > application it cannot be assumed it can handle unsupported > Vendor-Specific > Commands. For example, while an accounting server can handle > Vendor-Specific AVPs within an ACA by writing them to disk, it cannot > assume that a Vendor-Specific Command is equivalent to an ACA, and > carry out the same operation." > > > When possible, a new Diameter accounting application > SHOULD attempt > > to re-use any existing Diameter AVP, in order to reduce the > > possibility of having multiple AVPs that carry similar > information. > > > > Every Diameter accounting application specification MUST > have an IANA > > assigned Application Identifier (see section 2.4). > > > > 1.2.6 Application Authentication Procedures > > > > When possible, applications SHOULD be designed such that new > > authentication methods MAY be added without requiring > changes to the > > application. > > Note that this contradicts earlier text which was requested > to be removed. > > > This MAY require that new AVP values be assigned to > > represent the new authentication transform, or any other > scheme that > > produces similar results. When possible, authentication > frameworks, > > such as Extensible Authentication Protocol [EAP], SHOULD be used. > > From owner-aaa-wg@merit.edu Fri Jun 14 11:56: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 LAA04285 for ; Fri, 14 Jun 2002 11:56:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73B7591347; Fri, 14 Jun 2002 11:56:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44CA291348; Fri, 14 Jun 2002 11:56: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 2B2F791347 for ; Fri, 14 Jun 2002 11:56:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C659F5DE6F; Fri, 14 Jun 2002 11:56:13 -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 E32A55DE5C for ; Fri, 14 Jun 2002 11:56:12 -0400 (EDT) Received: from fmorn1dcode948i (c35.local.ipunplugged.com [192.168.4.234]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g5EFv7Ug016133; Fri, 14 Jun 2002 17:57:07 +0200 From: "Fredrik Johansson" To: "Bernard Aboba" , Cc: , , , Subject: [AAA-WG]: RE: Decision time was: Mandatory Vendor-specific AVP's Date: Fri, 14 Jun 2002 17:56:55 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps a small modification can be in place to make it even clearer what messages are possible to send to what peer. Today a peer can advertise support for a number of different applications, e.g. nasreq, mobile ip or it can advertise itself as a relay node meaning that it can relay all messages without having to understand them. This also means that it can relay all future messages since they must follow the routing procedures determined by the base protocol. But there is no way to determine if such a node can support anything locally. And it is still possible that it can not relay a message unless it in its turn has a neighbour advertising relay. If we instead say that a peer can advertise which application it supports locally or know where to relay on a per application basis it can advertise it via the application specific IDs. It can also advertise relay if it has the possibility to relay any message, i.e. it in its turn has a peer advertising relay that it can send the message to. By doing this a peer will definitely know if a peer can either handle a message or pass it thru to another peer. Not just that it might be able to handle it locally or pass it thru, but there might be an error message coming back. Comments? /Fredrik > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: den 14 juni 2002 15:11 > To: john.loughney@nokia.com > Cc: fredrik.johansson@ipunplugged.com; dave@frascone.com; > taylor@nortelnetworks.com; dlwarren@nortelnetworks.com; aaa-wg@merit.edu > Subject: Re: Decision time was: Mandatory Vendor-specific AVP's > > > > 1.2 Approach to Extensibility > > > > The Diameter protocol is designed to be extensible. The extensibility > > includes: > > > > - Defining new AVP values. > > - Creating new AVPs > > - Creating new authentication/authorization applications > > - Creating new accounting applications > > - Application authentication procedures > > > > Reuse of existing AVP values, AVPs, applications and command > codes are > > is strongly recommended. Reuse simplifies standardization effort, > > implentation effort and avoids potential interoperability issues. > > change "are is strongly recommended" to "is RECOMMENDED." > change "implentation" to "implementation" > > > > > 1.2.1 Standardized Extensions Versus Vendor-Specific Extensions > > > > Diameter can be extended by standards track documents in the IETF. > > The benefit of this is that the extensions become Internet standards, > > allowing for wider possible deployment and higher assurance of > > interoperability. It is strongly recommended that extensions to > > Diameter be made by standards-track RFCs. > > > > Vendor-specific extensions are allowed, and MUST be > registered through > > IANA (see section 11.2). However, vendor-specific > extensions MUST NOT > > harm interoperability of standards-based Diameter implementations. > > Don't understand meaning of "extensions" here. Is this VSCs? VSAs? > Registration through IANA can't be mandatory for private extensions and > the sentence above seems to contradict text below. Recommend deleting the > above paragraph. > > > > > Vendor-specific commands MUST NOT be used where an existing > command plus a > > vendor-specific AVPs would the same objective. If this basic > precept is > > change "would the same" to "would meet the same" > > > followed, then most interoperability problems are solved. > > change "are solved" to "can be avoided". > > > Vendor-specific commands MUST NOT be sent in response to standard > > commands. Unsolicited VSCs > > sent from a AAA server to a NAS are to be treated as > non-mandatory. All > > Change this to: > > "Vendor-specific commands MUST NOT be sent except where they are known to > be supported as a result of capabilities negotiation between the peers. > Even where they are supported, Vendor-Specific commands MUST NOT be sent > in response to standard commands." > > > vendor-specific Diameter commands require Informational RFCs > documenting > > the command unless for Private Use as described in Section 11.2.1. > > > > As a general rule, any errors involving Vendor-specific AVP > marked with > > the 'M' bit are considered the fault of the side setting the > 'M' bit (see > > Section 4.1). > > Add: > > "A Diameter peer sending a command containing Vendor-Specific AVPs marked > with the 'M' bit, and receiving indication from its peer that this AVP is > not supported, SHOULD retry the command with the Vendor-Specific AVP > removed, if this is feasible. This enables interoperability for standard > applications extended with Vendor-Specific AVPs marked with the 'M' bit." > > > 1.2.2 Defining New AVP Values > > > > New applications should attempt to reuse AVPs defined in existing > > applications when possible, as opposed to creating new AVPs. For AVPs > > of type Enumerated, it is possible the application requires a new > > value to communicate some service-specific information. > > > > In order to allocate a new AVP value, a request MUST be sent to IANA > > [IANA], with a detailed explanation of the value and document on the > > value. > > > > 1.2.3 Creating New AVPs > > > > When no existing AVP can be used appropriately to communicate some > > service-specific information, a new AVP should be created. The new > > AVP being defined MUST follow one of the types listed in section 4.3. > > In the event that a logical grouping of AVPs is necessary, and > > multiple "groups" are possible in a given command, it is highly > > recommended that a Grouped AVP be used (see Section 4.5). > > > > In order to create a new AVP, a request MUST be sent to IANA, with a > > detailed explanation of the AVP, its type and possible values. > > Furthermore, the request MUST include the commands that would make > > use of the AVP. > > > > 1.2.4 Creating New Authentication Applications > > > > Should a new application require Diameter support, but it cannot fit > > within an existing application without requiring major changes to the > > specification, it may be desirable to create a new Diameter > > application. Major changes to an application include: > > Add "Another reason to create a new Diameter application is if an > extension cannot be implemented merely by adding AVPs to the dictionary, > requiring new code to be implemented on both both Diameter peers." > > > > > - Requiring a whole different set of mandatory AVPs to a command > > Not clear whether this means "AVPs marked with the 'M' bit" or "AVPs > required to be included within the command." I don't believe that a new > command is required just if some AVPs marked with the 'M' bit are added to > a command. > > > - Requiring a command that has a different number of round trips > > to satisfy a request (e.g. application foo has a command that > > requires one round trip, but new application bar has a command > > that requires two round trips to complete). > > - The method used to authenticate the user is drastically > > different from any existing application, and the authentication > > information cannot be carried within the AVPs defined in the > > application. > > Don't agree that this should require a new command. For example, why > should a NAS adding support for a new PPP authentication method require an > entirely new NASREQ application? This is particularly true since we > recommend the opposite and discuss use of EAP as an alternative later in > the section. Recommend deletion. > > > Note that the creation of a new application should be viewed as a > > last resort. > > > > New Diameter applications MUST define at least one Command Code, the > > expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY > > also define new AVPs. If the Diameter application has any accounting > > requirements, it MUST also specify the AVPs that are to be present in > > the Diameter Accounting messages (see section 9.3). > > > > When possible, a new Diameter application SHOULD attempt to re-use > > any existing Diameter AVP, in order to reduce the possibility of > > having multiple AVPs that carry similar information. > > > > Every Diameter application specification MUST have an IANA assigned > > Application Identifier (see section 2.4). > > > > 1.2.5 Creating New Accounting Applications > > > > Services that have an Application Identifier MUST use the same > > identifier also to identify the service when Diameter accounting is > > used. > > > > There are services that only require the use of Diameter accounting. > > Such services need to define the service specific AVPs that must be > > carried in the Accounting-Request/Answer messages, but do not need to > > define command codes. Application Identifiers are, however, still > > required for accounting due to the Diameter capability discovery > > This might create some interoperability problems as discussed below. > > > process. Every accounting application MUST have either an IANA > > allocated Application Identifier, or a vendor specific Application > > Identifier. > > > > Note that the creation of a new application should be viewed as a > > last resort and should be used only when Vendor-Specific AVPs are > > insufficient. In most cases, reusing an existing Application ID with > > Vendor-Specific AVPs should work. For example, many accounting > > servers are set up to write AVPs to disk, so they can handle even > > mandatory vendor-specific AVPs that they don't understand. > > Change "mandatory vendor-specific AVPs that they don't understand" to > "even Vendor-Specific AVPs marked with the 'M' bit that are unsupported." > > > > > This is why "disk writing" accounting servers should advertise > > themselves as "Relays" that can handle any Application ID, including > > Vendor-Specific. > > Recommend adding: > > "Note that even when an accounting server advertises the "Relay" > application it cannot be assumed it can handle unsupported Vendor-Specific > Commands. For example, while an accounting server can handle > Vendor-Specific AVPs within an ACA by writing them to disk, it cannot > assume that a Vendor-Specific Command is equivalent to an ACA, and > carry out the same operation." > > > When possible, a new Diameter accounting application SHOULD attempt > > to re-use any existing Diameter AVP, in order to reduce the > > possibility of having multiple AVPs that carry similar information. > > > > Every Diameter accounting application specification MUST have an IANA > > assigned Application Identifier (see section 2.4). > > > > 1.2.6 Application Authentication Procedures > > > > When possible, applications SHOULD be designed such that new > > authentication methods MAY be added without requiring changes to the > > application. > > Note that this contradicts earlier text which was requested to be removed. > > > This MAY require that new AVP values be assigned to > > represent the new authentication transform, or any other scheme that > > produces similar results. When possible, authentication frameworks, > > such as Extensible Authentication Protocol [EAP], SHOULD be used. From owner-aaa-wg@merit.edu Mon Jun 17 21:56: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 VAA25561 for ; Mon, 17 Jun 2002 21:56:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0EB69124C; Mon, 17 Jun 2002 21:56:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81C1191250; Mon, 17 Jun 2002 21:56:06 -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 052A39124C for ; Mon, 17 Jun 2002 21:56:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA5C85DE3B; Mon, 17 Jun 2002 21:55:59 -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 974095DDF5 for ; Mon, 17 Jun 2002 21:55:58 -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 JAA28460 for ; Tue, 18 Jun 2002 09:52:25 +0800 (CST) Received: from PennyGuo ([202.38.197.70]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g5I1grUB018062 for ; Tue, 18 Jun 2002 09:42:53 +0800 (CST) Message-Id: <200206180142.g5I1grUB018062@letterbox.scut.edu.cn> Date: Tue, 18 Jun 2002 10:0:23 +0800 From: Penny To: "aaa-wg@merit.edu" Subject: [AAA-WG]: Who has used SUN aaaapi examle? X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====002_Dragon741011237411_=====" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --=====002_Dragon741011237411_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IEkgaGF2ZSBkb3dubG9hZGVkIFNVTldhYWFsLTBbMV0uNy4xLTEuaTM4Ni5ycG0gYW5kIGFhYWFw aS1leGFtcGxlLTFbMV0uMC4xLnRneiBmcm9tIHN1bi5jb20sIGFmdGVyIEkgaW5zdGFsbCBTVU5X YWFhbC0wWzFdLjcuMS0xLmkzODYucnBtLCBJIGVudGVyIGFhYWFwaS1leGFtcGxlLTEuMC4xIGRp cmVjdG9yeSwgIGFmdGVyIEkgbWFrZSBsaW51eCwgSSBydW4icnVuQ2xpZW50LnNoIiBhbmQgaXQg cmVwb3J0cyB0aGF0IA0KVW5hYmxlIHRvIGRsb3BlbiAibGlieG1sMi5zbyINClVuYWJsZSB0byBp bml0aWFsaXplIERpYW1ldGVyIExpYnJhcnkNCkkgYW0gY29uZnVzZWQgd2l0aCBpdC4gQ2FuIGFu eW9uZSBoZWxwIG1lIHdpdGggdGhpcyBwcm9ibGVtPyBUaGFuayB5b3UgdmVyeSBtdWNoLg0K --=====002_Dragon741011237411_===== Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPFA+Jm5ic3A7SSBoYXZl IGRvd25sb2FkZWQgU1VOV2FhYWwtMFsxXS43LjEtMS5pMzg2LnJwbSBhbmQgDQphYWFhcGktZXhh bXBsZS0xWzFdLjAuMS50Z3ogZnJvbSBzdW4uY29tLCBhZnRlciBJIGluc3RhbGwgDQpTVU5XYWFh bC0wWzFdLjcuMS0xLmkzODYucnBtLCZuYnNwO0kgZW50ZXIgYWFhYXBpLWV4YW1wbGUtMS4wLjEg ZGlyZWN0b3J5LCZuYnNwOyANCmFmdGVyIEkgbWFrZSBsaW51eCwgSSBydW4icnVuQ2xpZW50LnNo IiBhbmQgaXQgcmVwb3J0cyB0aGF0IDwvUD4NCjxQPlVuYWJsZSB0byBkbG9wZW4gImxpYnhtbDIu c28iPEJSPlVuYWJsZSB0byBpbml0aWFsaXplIERpYW1ldGVyIExpYnJhcnk8L1A+DQo8UD5JIGFt IGNvbmZ1c2VkIHdpdGggaXQuIENhbiBhbnlvbmUgaGVscCBtZSB3aXRoIHRoaXMgcHJvYmxlbT8g VGhhbmsgeW91IHZlcnkgDQptdWNoLjwvUD48L0JPRFk+PC9IVE1MPg0K --=====002_Dragon741011237411_=====-- From owner-aaa-wg@merit.edu Tue Jun 18 05: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 FAA10589 for ; Tue, 18 Jun 2002 05:01:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29AC391258; Tue, 18 Jun 2002 05:01:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4E3691259; Tue, 18 Jun 2002 05:01:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3AFA491258 for ; Tue, 18 Jun 2002 05:01:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 161B35DE12; Tue, 18 Jun 2002 05:01:12 -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 A99C45DDB8 for ; Tue, 18 Jun 2002 05:01:10 -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 QAA14188 for ; Tue, 18 Jun 2002 16:57:37 +0800 (CST) Received: from PennyGuo ([202.38.197.70]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g5I8m5UB007162 for ; Tue, 18 Jun 2002 16:48:05 +0800 (CST) Message-Id: <200206180848.g5I8m5UB007162@letterbox.scut.edu.cn> Date: Tue, 18 Jun 2002 17:5:35 +0800 From: Penny To: "aaa-wg@merit.edu" Subject: Re: Re: [AAA-WG]: Who has used SUN aaaapi examle? X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====002_Dragon465447158360_=====" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --=====002_Dragon465447158360_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gY2F1c2VkIGJ5IGxpYnhtbDIuc28gaXMgYmVjYXVzZSBJIGhhdmVuJ3QgaW5z dGFsbGVkIGxpYnhtbC4gQW5kIEkgd2lsbCBub3QgYXNrIGRpYW1ldGVyIHF1ZXN0aW9uIGluIGFh YSB3b3JrIGdyb3VwLCBzb3JyeS4NCj4gSSBoYXZlIGRvd25sb2FkZWQgU1VOV2FhYWwtMFsxXS43 LjEtMS5pMzg2LnJwbSBhbmQNCj4gYWFhYXBpLWV4YW1wbGUtMVsxXS4wLjEudGd6IGZyb20gc3Vu LmNvbSwgYWZ0ZXIgSSBpbnN0YWxsDQo+IFNVTldhYWFsLTBbMV0uNy4xLTEuaTM4Ni5ycG0sIEkg ZW50ZXIgYWFhYXBpLWV4YW1wbGUtMS4wLjEgZGlyZWN0b3J5LA0KPiBhZnRlciBJIG1ha2UgbGlu dXgsIEkgcnVuInJ1bkNsaWVudC5zaCIgYW5kIGl0IHJlcG9ydHMgdGhhdA0KPg0KPiBVbmFibGUg dG8gZGxvcGVuICJsaWJ4bWwyLnNvIg0KPiBVbmFibGUgdG8gaW5pdGlhbGl6ZSBEaWFtZXRlciBM aWJyYXJ5DQo+DQo+IEkgYW0gY29uZnVzZWQgd2l0aCBpdC4gQ2FuIGFueW9uZSBoZWxwIG1lIHdp dGggdGhpcyBwcm9ibGVtPyBUaGFuayB5b3UNCj4gdmVyeSBtdWNoLg0KPg0K --=====002_Dragon465447158360_===== Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPFA+VGhlIHByb2JsZW0g Y2F1c2VkIGJ5IGxpYnhtbDIuc28gaXMgYmVjYXVzZSBJIGhhdmVuJ3QgaW5zdGFsbGVkIGxpYnht bC4gQW5kIEkgDQp3aWxsIG5vdCBhc2sgZGlhbWV0ZXIgcXVlc3Rpb24gaW4gYWFhIHdvcmsgZ3Jv dXAsIHNvcnJ5LjwvUD4NCjxQPiZndDsgSSBoYXZlIGRvd25sb2FkZWQgU1VOV2FhYWwtMFsxXS43 LjEtMS5pMzg2LnJwbSBhbmQ8QlI+Jmd0OyANCmFhYWFwaS1leGFtcGxlLTFbMV0uMC4xLnRneiBm cm9tIHN1bi5jb20sIGFmdGVyIEkgaW5zdGFsbDxCUj4mZ3Q7IA0KU1VOV2FhYWwtMFsxXS43LjEt MS5pMzg2LnJwbSwgSSBlbnRlciBhYWFhcGktZXhhbXBsZS0xLjAuMSBkaXJlY3RvcnksPEJSPiZn dDsgDQphZnRlciBJIG1ha2UgbGludXgsIEkgcnVuInJ1bkNsaWVudC5zaCIgYW5kIGl0IHJlcG9y dHMgdGhhdDxCUj4mZ3Q7PEJSPiZndDsgDQpVbmFibGUgdG8gZGxvcGVuICJsaWJ4bWwyLnNvIjxC Uj4mZ3Q7IFVuYWJsZSB0byBpbml0aWFsaXplIERpYW1ldGVyIA0KTGlicmFyeTxCUj4mZ3Q7PEJS PiZndDsgSSBhbSBjb25mdXNlZCB3aXRoIGl0LiBDYW4gYW55b25lIGhlbHAgbWUgd2l0aCB0aGlz IA0KcHJvYmxlbT8gVGhhbmsgeW91PEJSPiZndDsgdmVyeSBtdWNoLjxCUj4mZ3Q7PC9QPjwvQk9E WT48L0hUTUw+DQo= --=====002_Dragon465447158360_=====-- From owner-aaa-wg@merit.edu Tue Jun 18 15:11:45 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 PAA01146 for ; Tue, 18 Jun 2002 15:11:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87639912D3; Tue, 18 Jun 2002 15:04:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7532912E6; Tue, 18 Jun 2002 15:04:41 -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 611D7912D3 for ; Tue, 18 Jun 2002 15:04:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F2BB5DEC0; Tue, 18 Jun 2002 15:04:34 -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 DE2725DE1A for ; Tue, 18 Jun 2002 15:04:33 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g5IJ4Xi27696 for ; Tue, 18 Jun 2002 14:04:33 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g5IJ4X803757 for ; Tue, 18 Jun 2002 14:04:33 -0500 (CDT) Received: FROM ericsson.com BY eamrcnt749 ; Tue Jun 18 14:04:32 2002 -0500 Message-ID: <3D0F8348.7B30E610@ericsson.com> Date: Tue, 18 Jun 2002 12:00:33 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> <3CFBC769.A32542FA@Interlinknetworks.com> <3CFBF3A8.332BDEBA@ericsson.com> <3CFC161D.6624C24@Interlinknetworks.com> <3CFCF4D4.9E7B34CA@ericsson.com> <3CFD0E6B.67B5D24E@Interlinknetworks.com> <3CFD36E9.16743375@ericsson.com> <3CFE7134.DAD3DC77@Interlinknetworks.com> <3D0138B3.4654B4B6@ericsson.com> <3D0265DF.67CE7908@Interlinknetworks.com> <3D03B571.30768671@ericsson.com> <3D04B959.8DE94178@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, All, Finally coming back to this one. David Spence wrote: > Tony, > > See comments inline. > > Tony Johansson wrote: > > > > Hi David, all, > > > > David Spence wrote: > > > > > Tony, > > > > > > First of all, I am not sure that I do agree that an AAAH cannot be > > > stateless. Our initial implementation of a Diameter server was stateless > > > and at the time we thought that we could correctly implement the protocol. > > > I am not aware of any reason other than this issue that would prevent an > > > AAAH from being session stateless. If you know of any, I would very much > > > appreciate it if you would let me know. > > > > Being session stateless according to the Base protocol is that you only maintains > > transaction state. However, a MIP AAAH server do have to handle the authentication, > > authorization, etc of the user, > > I don't think auth/auth mandates being session stateful. > > > and furthermore must expect to get STRs > > A session-stateless AAAH doesn't really have to do anything with an > FA-generated STR except perhaps to write it to a log file. Is the same not > true of an HA-generated STR? If an AAAH receives an STR from an HA, it is > not required to send an ABR to the FA is it? The FA will see the tunnel go > down and generate an STR. > > > or send ABRs for an expired session-id that an active user may have, > > ABRs and session timeouts are defined in the base protocol. My > understanding is that the home Diameter server is not required to send an > ABR to enforce a timeout. That is the responsibility of the Diameter > client. This is merely one use of the ASR. Another potential use would be to administratively terminate a user session (yet another reason why you need to remember the session-id and hence be session-stateful). > > > > so strictly form a protocol > > prospective, can you really say that the MIP AAAH server can be a stateless Diameter > > agent? > > Yes, the AAAH can be a stateless Diameter node! (It is not a Diameter > agent, strictly speaking.) > > > > > Furthermore, based on all the previous session stateless AAAH discussions, > > implementing the MIP application with a *session stateless* AAAH wouldn't you still > > store the FA session id and the HA session id in the AAAH (or in away that the AAAH > > easily can retrieve them (e.g. through a back ended database)) in order to deal with > > STRs from the HA, > > Once again, I didn't think it was necessary to match Session-Ids in order to > handle HA STRs. Am I mistaken about this? Yes, in MIP the AAAH MUST be able receive STRs from both FAs and the HA (which in fact means match Session-Ids). So, if the AAAH is session-stateless according to the base it would not be expecting to get any STRs, since it would have announced that it is don't maintain state, see below: "8.11 Auth-Session-State AVP The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and specifies whether state is maintained for a particular session. The client MAY include this AVP in requests as a hint to the server, but the value in the server's answer message is binding. The following values are supported: STATE_MAINTAINED 0 This value is used to specify that session state is being maintained, and the access device MUST issue a session termination message when service to the user is terminated. This is the default value. NO_STATE_MAINTAINED 1 This value is used to specify that no session termination messages will be sent by the access device upon expiration of the Authorization-Lifetime." So, my point is again is that the AAAH cannot be session-stateless according to the base, since it still must be able to keep track of the active sessions. Again, have in mind that we are addressing the issue of protocol statefulness and *NOT* implementation statefulness. Other's comments would be greatly appreciated. /Tony From owner-aaa-wg@merit.edu Tue Jun 18 23:12: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 XAA12754 for ; Tue, 18 Jun 2002 23:12:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2AA591297; Tue, 18 Jun 2002 23:13:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 703F691298; Tue, 18 Jun 2002 23:13: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 541AD91297 for ; Tue, 18 Jun 2002 23:13:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C36C5DEB6; Tue, 18 Jun 2002 23:13:02 -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 9AC9F5DE77 for ; Tue, 18 Jun 2002 23:13:00 -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 LAA09313 for ; Wed, 19 Jun 2002 11:09:27 +0800 (CST) Received: from PennyGuo ([202.38.197.70]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g5J2xsUB008083 for ; Wed, 19 Jun 2002 10:59:54 +0800 (CST) Message-Id: <200206190259.g5J2xsUB008083@letterbox.scut.edu.cn> Date: Wed, 19 Jun 2002 11:17:29 +0800 From: Penny To: "aaa-wg@merit.edu" Subject: [AAA-WG]: inter-A's communication? X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====002_Dragon276626063254_=====" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --=====002_Dragon276626063254_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 V2Uga25vdyB0aGF0IHRoZSBjb21tdW5pY2F0aW9ucyBhbW9uZyBBQUEgc2VydmVycyBhbmQgQUFB IGNsaWVudHMgYXJlIHZpYSBSQURJVVMgb3IgRElBTUVURVIsZXRjIC4gQnV0IGhvdyBkbyBBdXRo ZW50aWNhdGlvbiwgQXV0aG9yaXphdGlvbiBhbmQgQWNjb3VudGluZyBjb21tdW5pY2F0ZSB3aXRo IGVhY2ggb3RoZXI/DQo= --=====002_Dragon276626063254_===== Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPldlIGtub3cgdGhhdCB0aGUg Y29tbXVuaWNhdGlvbnMgYW1vbmcgQUFBIHNlcnZlcnMgYW5kIEFBQSBjbGllbnRzJm5ic3A7YXJl IA0KdmlhIFJBRElVUyBvciBESUFNRVRFUixldGMgLiBCdXQgaG93IGRvIEF1dGhlbnRpY2F0aW9u LCBBdXRob3JpemF0aW9uIGFuZCANCkFjY291bnRpbmcgY29tbXVuaWNhdGUgd2l0aCBlYWNoIG90 aGVyPzwvQk9EWT48L0hUTUw+DQo= --=====002_Dragon276626063254_=====-- From owner-aaa-wg@merit.edu Sun Jun 23 00:38: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 AAA10947 for ; Sun, 23 Jun 2002 00:38:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2724E91211; Sun, 23 Jun 2002 00:39:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E32669123C; Sun, 23 Jun 2002 00:39: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 DCF0791211 for ; Sun, 23 Jun 2002 00:39:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB5EB5DDC5; Sun, 23 Jun 2002 00:39:03 -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 6E0D45DDAE for ; Sun, 23 Jun 2002 00:39:03 -0400 (EDT) Received: from GWZW2K (sjc-vpn2-981.cisco.com [10.21.115.213]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA17887; Sat, 22 Jun 2002 21:39:02 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "AAA WG" Cc: "Glen Zorn" , "David Spence" Subject: [AAA-WG]: NASREQ Date: Sat, 22 Jun 2002 21:38:56 -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) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 9.1 of draft-ietf-aaa-diameter-nasreq-09.txt says (in part): This section describes the actions that should be followed when a protocol Gateway receives a RADIUS message that is to be translated to a Diameter message. When a protocol gateway receives a RADIUS message, the following steps should be taken: ... - If the NAS-IP-Address attribute is present in the RADIUS message, the name MUST be translated to its corresponding FQDN, and encoded in the Diameter message's Origin-Host AVP. If the NAS-Identifier attribute is present, the data can be used in the Origin-Host AVP. - The Origin-Host AVP is added with the local server's identity. This will ensure that the corresponding response will be returned to the correct gateway server. The aaa protocol specified in the identity would be set to "radius". This seems to suggest that there will be _two_ Origin-Host AVPs in the resulting AAR, but as I read it, only one Origin-Host AVP is allowed. Also, since we have NAS-IP-Address and NAS-Identifier AVPs, why not use them? From owner-aaa-wg@merit.edu Sun Jun 23 10:51: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 KAA27600 for ; Sun, 23 Jun 2002 10:51:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B49799123C; Sun, 23 Jun 2002 10:52:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 827C79123E; Sun, 23 Jun 2002 10:52:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65F589123C for ; Sun, 23 Jun 2002 10:52:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 481C15DDD5; Sun, 23 Jun 2002 10:52:20 -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 3FCF65DDCF for ; Sun, 23 Jun 2002 10:52:11 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Sun, 23 Jun 2002 07:52:02 -0700 Message-ID: From: "Pat R. Calhoun" To: "'gwz@cisco.com'" , AAA WG Cc: David Spence Subject: RE: [AAA-WG]: NASREQ Date: Sun, 23 Jun 2002 07:52:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_00DD_01C21A8A.DAD9A1A0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DD_01C21A8A.DAD9A1A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hmmm... This seems like a bug. The RADIUS attributes must be translated to something, but Only the gateway's identity must be in the Origin-Host AVP. PatC -----Original Message----- From: Glen Zorn [mailto:gwz@cisco.com] Sent: Saturday, June 22, 2002 9:39 PM To: AAA WG Cc: Glen Zorn; David Spence Subject: [AAA-WG]: NASREQ Section 9.1 of draft-ietf-aaa-diameter-nasreq-09.txt says (in part): This section describes the actions that should be followed when a protocol Gateway receives a RADIUS message that is to be translated to a Diameter message. When a protocol gateway receives a RADIUS message, the following steps should be taken: ... - If the NAS-IP-Address attribute is present in the RADIUS message, the name MUST be translated to its corresponding FQDN, and encoded in the Diameter message's Origin-Host AVP. If the NAS-Identifier attribute is present, the data can be used in the Origin-Host AVP. - The Origin-Host AVP is added with the local server's identity. This will ensure that the corresponding response will be returned to the correct gateway server. The aaa protocol specified in the identity would be set to "radius". This seems to suggest that there will be _two_ Origin-Host AVPs in the resulting AAR, but as I read it, only one Origin-Host AVP is allowed. Also, since we have NAS-IP-Address and NAS-Identifier AVPs, why not use them? ------=_NextPart_000_00DD_01C21A8A.DAD9A1A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJATCCApAw ggH5oAMCAQICAwer/jANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAyMDYxMTIxMTczMFoXDTAzMDYxMTIxMTczMFowTTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYbcGNhbGhvdW5AYnN0b3JtbmV0d29ya3Mu Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDk38Z+sZL75flWWN93wXdkkO7S55TvADnY EojA53bWhOfS1fmLHhr1vuqXIcWGOYYR1yesETMSYDns2vErJEYJWj8L0RA0pdy9S1GtZzgRB2uj s/ORyexFZiL3nbQwdZ3QzUGUK03j0LDW3ajPyk68gksjRNVg3PTj3vuydoGk9QIDAQABozgwNjAm BgNVHREEHzAdgRtwY2FsaG91bkBic3Rvcm1uZXR3b3Jrcy5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQBDKmH+TxEAAiUiSK1t+d2xyymUPIm66UZxmiLmpaQMQYbFZCirJobT5eWF CEUMpkojiU+WecDJBlobpcOAyyyCVO/JIShmlcSPeaYHm+Ofcdi3xfhHtGMOMrNA3oV6NvrAjd8g XMMe8l0kN9Ul862NQrdKMRHeFy5csmznEyeakDCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEE BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAw MDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl MRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97 Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3q wF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8G A1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGs JrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T 9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM4MIICoaAD AgECAhBmRXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBD b25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFs LWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8w DQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9Q ZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNP omXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH /7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0 ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEE BQADgYEAMbFLR135AXHl9VNsXXnWPZjAJhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQ Vahs9w2tTBu8A/S166JHn2yiDFiNMUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2 ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggNpMIIDZQIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMHq/4wCQYFKw4DAhoFAKCCAiQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDIwNjIzMTQ1MTU5WjAjBgkqhkiG9w0BCQQxFgQUH4SaOkOK/uS1 adD5MooH6apOMwgwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcN AgUwgasGCSsGAQQBgjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw AgMHq/4wga0GCyqGSIb3DQEJEAILMYGdoIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMU Q2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzACAwer/jANBgkqhkiG9w0BAQEFAASBgBkiT5g7KS/q4TuabtTKT3Ty14vTd/p1go7/IuKR E+sxX9/YD3CMSqVWRjKtWb9Hzyd0/6KF/2nFPd8nO305vkw19o7N7FG3YmAX7aI63ykpk2/7vbkE dT35M+wsOiq2SVymr3ar6POz854V6L/gWSY43SybfOQvo6nejndq71u5AAAAAAAA ------=_NextPart_000_00DD_01C21A8A.DAD9A1A0-- From owner-aaa-wg@merit.edu Sun Jun 23 19:04:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05925 for ; Sun, 23 Jun 2002 19:04:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 05C8391201; Sun, 23 Jun 2002 19:04:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5D1291230; Sun, 23 Jun 2002 19:04: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 BF9A091201 for ; Sun, 23 Jun 2002 19:04:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5ABE5DE16; Sun, 23 Jun 2002 19:04:44 -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 2845D5DE12 for ; Sun, 23 Jun 2002 19:04:44 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-217.cisco.com [10.21.64.217]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id QAA18959; Sun, 23 Jun 2002 16:04:27 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , Cc: "AAA WG" Subject: [AAA-WG]: Issue w/issue 308 Date: Sun, 23 Jun 2002 16:04:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: High X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 Mon Jun 24 08: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 IAA03516 for ; Mon, 24 Jun 2002 08:36:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C9F591208; Mon, 24 Jun 2002 08:35:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 287CD9120C; Mon, 24 Jun 2002 08:35: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 F3F1C91208 for ; Mon, 24 Jun 2002 08:35:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D74645DE1D; Mon, 24 Jun 2002 08:35:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 034525DDAE for ; Mon, 24 Jun 2002 08:35:43 -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 g5OCbVW04475 for ; Mon, 24 Jun 2002 15:37:31 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Jun 2002 15:35:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 24 Jun 2002 15:35: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]: Vendor Command Code resolution Date: Mon, 24 Jun 2002 15:35:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E68@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Base Updated section 1.2 Thread-Index: AcIS6l9G1LLFnIk5S0SOaGV62iWRfAIi2Hjw From: To: X-OriginalArrivalTime: 24 Jun 2002 12:35:41.0835 (UTC) FILETIME=[A71BF5B0:01C21B7B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03516 Hi all, Here is a summary of the direction taken during a discussion with 3GPP. The main issue is that VSCs generally require understanding in an implementation. Currently, we have no way to manage communication between implementations where there is not support for VSCs that are sent by a Diameter peer. There is high-level concern that use of VSCs will great interoperability problems. Standardization of command codes are prefered. Standardization bodies using Diameter extensions are strongly encouraged to standardize these. In summary, what is needed to the base specification is: a. Eliminate vendor-specific commands, but keep vendor-specific AVPs. b. Carve out an "experimental" playpen space within the existing command space, where vendors can create experimental commands. c. Allow use of Application IDs in a broader set of circumstances: 1. To indicate support for a set of vendor-specific AVPs with the 'M' bit set 2. To indicate support for an "experimental" command As a result, it will no longer be required that an application have a new command (standard or vendor-specific) associated with it. Some implications of this: d. The CER/CEA exchange should prevent sending of Vendor-Specific AVPs with the 'M' bit set to peers that do not support those AVPs. This means that the Diameter peers won't need to retry without 'M' bit AVPs after an "unrecognized AVP" error. e. Conflicts between "experimental" commands are avoided as long as the application IDs are unique. f. The Application ID space needs to be partioned between "applications with new 'M' bit AVPs, but no new commands" and "applications with commands." Reasons for this are described in g. g. Two types of generic advertisement are needed. Today we have the "Relay" advertisement that implies "all applications." But we also need an "any AVPs" advertisement for Accounting Servers. This allows an Accounting Server to advertise that it can accept any AVP, without also implying that it can handle any "experimental" command thrown at it, which is difficult or impossible to support in practice. Note that if this were not done then we would undermine capabilities negotiation, since peers could advertise capabilities they didn't really support. best regards, John PS - thanks to Bernard who wrote down the proposal from our conference call. From owner-aaa-wg@merit.edu Mon Jun 24 22:09: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 WAA10054 for ; Mon, 24 Jun 2002 22:09:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88E9B91220; Mon, 24 Jun 2002 22:09:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56CCF91222; Mon, 24 Jun 2002 22:09: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 5CC7C91220 for ; Mon, 24 Jun 2002 22:09:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A8755DE34; Mon, 24 Jun 2002 22:09:42 -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 F2EBF5DE1F for ; Mon, 24 Jun 2002 22:09:41 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-403.cisco.com [10.21.65.147]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA08119; Mon, 24 Jun 2002 19:09:37 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Mon, 24 Jun 2002 19:09:34 -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: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E68@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@nokia.com writes: > Hi all, > > Here is a summary of the direction taken during a discussion with > 3GPP. So is this an actual proposal, a meeting report, or the report of a decision (ordinarily I would never suggest the last, since this is the IETF, but it has that tone...). > > The main issue is that VSCs generally require understanding in an > implementation. Currently, we have no way to manage communication > between implementations where there is not support for VSCs that > are sent by a Diameter peer. That depends upon how you define "manage communication". At the risk of becoming tediously repetitive, I pointed out on this list more than two weeks ago (to thundering silence) that there already exists a well-defined method to handle unrecognized commands (vendor-specific or otherwise). For convenience, I'll quote it here: "...if a vendor-specific request is sent to a box that doesn't support it, the resulting answer (same command code for easy identification) will have the E bit set and a result code of DIAMETER_COMMAND_UNSUPPORTED. How much simpler (sic) can you get?". Of course, that doesn't help to avoid sending the inappropriate command in the first place. However, there is an easy way to fix this: simply make the relationship between application and command code reciprocal. Right now, I believe that the creation of a new application requires the creation of a new command code but not vice-versa please correct me if I'm wrong). In my mind, anyway, this relationship has always been reciprocal (i.e., the introduction of a new command _requires_ the use of a new application ID. If this is done, then I believe that (presupposing that no lying takes place during the capabilities exchange process) that it would be impossible to send a command that is unsupported by the peer. > There is high-level concern that > use of VSCs will great interoperability problems. If by "high-level" you mean the IESG, my understanding is that the concerns have more to do with the assignation of blame for lack of interoperability than the interoperability problems themselves (maybe Randy can comment on this). Currently, I believe that it would not be a protocol violation to add a VSC to a standard application (say, NASREQ) and claim that the result is "Diameter", This is a problem, but I think that my above proposal closes that loophole. > Standardization of > command codes are prefered. Standardization bodies using Diameter > extensions are strongly encouraged to standardize these. I assume that by "standardize these" you mean "standardize these in the IETF". Unfortunately, standardization in the IETF can be a long process and as we have noticed deadlines of organizations outside the IETF (e.g., 3GPP & 3GPP2) have little effect upon the speed of the process. For example, 3GPP2 has been waiting for the IETF to standardize Diameter for almost 4 years now; would they (or 3GPP) be pleased to tie their release to what is essentially a nondeterministic process? > > In summary, what is needed to the base specification is: > > a. Eliminate vendor-specific commands, but keep vendor-specific AVPs. > > b. Carve out an "experimental" playpen space within the existing command > space, where vendors can create experimental commands. > > c. Allow use of Application IDs in a broader set of circumstances: > 1. To indicate support for a set of vendor-specific AVPs with the 'M' > bit set > 2. To indicate support for an "experimental" command > > As a result, it will no longer be required that an application have a new > command (standard or vendor-specific) associated with it. > > Some implications of this: > > d. The CER/CEA exchange should prevent sending of Vendor-Specific AVPs > with the 'M' bit set to peers that do not support those AVPs. > This means > that the Diameter peers won't need to retry without 'M' bit > AVPs after an > "unrecognized AVP" error. > > e. Conflicts between "experimental" commands are avoided as long as the > application IDs are unique. > > f. The Application ID space needs to be partioned between > "applications with new 'M' bit AVPs, but no new commands" and > "applications with commands." Reasons for this are described in g. "g." discusses only accounting; since the "standard" accounting service just logs stuff, the use of the 'M' bit seems uncessary. So if 3GPP wants to be able to set the 'M' bit on VSAs, why? > > g. Two types of generic advertisement are needed. Today we have the > "Relay" advertisement that implies "all applications." But we > also need > an "any AVPs" advertisement for Accounting Servers. This allows an > Accounting Server to advertise that it can accept any AVP, > without also > implying that it can handle any "experimental" command thrown at it, > which is difficult or impossible to support in practice. There is no need for a new advertisement: simply make the Acct-Application-Id AVP required in all accounting and capabilities exchange messages, and define a value for it in the base protocol that means "Standard". > > Note that if this were not done then we would undermine capabilities > negotiation, since peers could advertise capabilities they didn't really > support. > > best regards, > John > > PS - thanks to Bernard who wrote down the proposal from our > conference call. > > From owner-aaa-wg@merit.edu Tue Jun 25 00:16: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 AAA12717 for ; Tue, 25 Jun 2002 00:16:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E72891244; Tue, 25 Jun 2002 00:17:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D668791245; Tue, 25 Jun 2002 00:17: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 ADCB691244 for ; Tue, 25 Jun 2002 00:17:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CD8F5DE3F; Tue, 25 Jun 2002 00:17: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 E57F45DE3A for ; Tue, 25 Jun 2002 00:17: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 g5P4J1W10944 for ; Tue, 25 Jun 2002 07:19:01 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Jun 2002 07:17:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 25 Jun 2002 07:17:11 +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]: Vendor Command Code resolution Date: Tue, 25 Jun 2002 07:17:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E6B@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIb7V5CCr1mrjieQEacUPG34Ai/mAAD7Vmg From: To: , X-OriginalArrivalTime: 25 Jun 2002 04:17:11.0721 (UTC) FILETIME=[2DB48190:01C21BFF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA12717 Hi Glen, > So is this an actual proposal, a meeting report, or the report of a decision > (ordinarily I would never suggest the last, since this is the IETF, but it > has that tone...). Sorry for the tone, it is a strong proposal. What I mean by that, is that the IESG has stated that they are not comfortable with VSCs and this needs to be resolved before Diameter can be Diameter can be progressed. 3GPP has 2 Diameter extentions, that use VSCs and so we are working on how to resolve the issue with as little pain to all of the parties involved. > > The main issue is that VSCs generally require understanding in an > > implementation. Currently, we have no way to manage communication > > between implementations where there is not support for VSCs that > > are sent by a Diameter peer. > > That depends upon how you define "manage communication". At the risk of > becoming tediously repetitive, I pointed out on this list more than two > weeks ago (to thundering silence) that there already exists a well-defined > method to handle unrecognized commands (vendor-specific or otherwise). For > convenience, I'll quote it here: "...if a vendor-specific request is sent to > a box that doesn't support it, the resulting answer (same command code for > easy identification) will have the E bit set and a result code of > DIAMETER_COMMAND_UNSUPPORTED. How much simpler (sic) can you get?". I haven't heard any feedback on this, I don't know if it is OK with the IESG, but I agree that this is simple & affective. > Of course, that doesn't help to avoid sending the inappropriate command in the > first place. However, there is an easy way to fix this: simply make the > relationship between application and command code reciprocal. Right now, I > believe that the creation of a new application requires the creation of a > new command code but not vice-versa please correct me if I'm wrong). In my > mind, anyway, this relationship has always been reciprocal (i.e., the > introduction of a new command _requires_ the use of a new application ID. > If this is done, then I believe that (presupposing that no lying takes place > during the capabilities exchange process) that it would be impossible to > send a command that is unsupported by the peer. I agree with you on the above. > > There is high-level concern that > > use of VSCs will great interoperability problems. > > If by "high-level" you mean the IESG, my understanding is that the concerns > have more to do with the assignation of blame for lack of interoperability > than the interoperability problems themselves (maybe Randy can comment on > this). Currently, I believe that it would not be a protocol violation to > add a VSC to a standard application (say, NASREQ) and claim that the result > is "Diameter", This is a problem, but I think that my above proposal closes > that loophole. In my personal opinion, standardizing new Diameter applications with new command codes is OK. I don't think it bothers the IESG. The unstandardized command codes is the bothersome bit. > > Standardization of > > command codes are prefered. Standardization bodies using Diameter > > extensions are strongly encouraged to standardize these. > > I assume that by "standardize these" you mean "standardize these in the > IETF". Unfortunately, standardization in the IETF can be a long process and > as we have noticed deadlines of organizations outside the IETF (e.g., 3GPP & > 3GPP2) have little effect upon the speed of the process. For example, 3GPP2 > has been waiting for the IETF to standardize Diameter for almost 4 years > now; would they (or 3GPP) be pleased to tie their release to what is > essentially a nondeterministic process? I hear you - no reason to preach to the converted. However, do you think that new command codes are really needed? I've heard from folks with much more Radius experience that new Radius command codes are fairly in frequent. > > > > In summary, what is needed to the base specification is: > > > > a. Eliminate vendor-specific commands, but keep > vendor-specific AVPs. > > > > b. Carve out an "experimental" playpen space within the > existing command > > space, where vendors can create experimental commands. > > > > c. Allow use of Application IDs in a broader set of circumstances: > > 1. To indicate support for a set of vendor-specific > AVPs with the 'M' > > bit set > > 2. To indicate support for an "experimental" command > > > > As a result, it will no longer be required that an > application have a new > > command (standard or vendor-specific) associated with it. > > > > Some implications of this: > > > > d. The CER/CEA exchange should prevent sending of > Vendor-Specific AVPs > > with the 'M' bit set to peers that do not support those AVPs. > > This means > > that the Diameter peers won't need to retry without 'M' bit > > AVPs after an > > "unrecognized AVP" error. > > > > e. Conflicts between "experimental" commands are avoided as > long as the > > application IDs are unique. > > > > f. The Application ID space needs to be partioned between > > "applications with new 'M' bit AVPs, but no new commands" and > > "applications with commands." Reasons for this are > described in g. > > "g." discusses only accounting; since the "standard" accounting service just > logs stuff, the use of the 'M' bit seems uncessary. So if 3GPP wants to be > able to set the 'M' bit on VSAs, why? Let me look into this. > > g. Two types of generic advertisement are needed. Today we have the > > "Relay" advertisement that implies "all applications." But we > > also need > > an "any AVPs" advertisement for Accounting Servers. This > allows an > > Accounting Server to advertise that it can accept any AVP, > > without also > > implying that it can handle any "experimental" command > thrown at it, > > which is difficult or impossible to support in practice. > > There is no need for a new advertisement: simply make the > Acct-Application-Id AVP required in all accounting and capabilities exchange > messages, and define a value for it in the base protocol that means > "Standard". That might work. thanks for the comments, John From owner-aaa-wg@merit.edu Tue Jun 25 01:01: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 BAA13702 for ; Tue, 25 Jun 2002 01:01:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32BAB91245; Tue, 25 Jun 2002 01:00:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E855E91246; Tue, 25 Jun 2002 01:00: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 3760F91245 for ; Tue, 25 Jun 2002 01:00:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 160735DE3A; Tue, 25 Jun 2002 01:00:22 -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 BB7B75DE1F for ; Tue, 25 Jun 2002 01:00:21 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-403.cisco.com [10.21.65.147]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id WAA01357; Mon, 24 Jun 2002 22:00:17 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Mon, 24 Jun 2002 22:00:13 -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: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E6B@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@nokia.com [mailto:john.loughney@nokia.com] writes: > Hi Glen, > > > So is this an actual proposal, a meeting report, or the report > of a decision > > (ordinarily I would never suggest the last, since this is the > IETF, but it > > has that tone...). > > Sorry for the tone, it is a strong proposal. OK, thanks for the clarification. > What I mean by that, is that > the IESG has stated that they are not comfortable with VSCs and this needs > to be resolved before Diameter can be Diameter can be progressed. 3GPP > has 2 Diameter extentions, that use VSCs and so we are working on how to > resolve the issue with as little pain to all of the parties involved. > > > > The main issue is that VSCs generally require understanding in an > > > implementation. Currently, we have no way to manage communication > > > between implementations where there is not support for VSCs that > > > are sent by a Diameter peer. > > > > That depends upon how you define "manage communication". At the risk of > > becoming tediously repetitive, I pointed out on this list more than two > > weeks ago (to thundering silence) that there already exists a > well-defined > > method to handle unrecognized commands (vendor-specific or > otherwise). For > > convenience, I'll quote it here: "...if a vendor-specific > request is sent to > > a box that doesn't support it, the resulting answer (same > command code for > > easy identification) will have the E bit set and a result code of > > DIAMETER_COMMAND_UNSUPPORTED. How much simpler (sic) can you get?". > > I haven't heard any feedback on this, I don't know if it is OK > with the IESG, > but I agree that this is simple & affective. Better yet, it's already in the protocol! > > > Of course, that doesn't help to avoid sending the inappropriate > command in the > > first place. However, there is an easy way to fix this: simply make the > > relationship between application and command code reciprocal. > Right now, I > > believe that the creation of a new application requires the > creation of a > > new command code but not vice-versa please correct me if I'm > wrong). In my > > mind, anyway, this relationship has always been reciprocal (i.e., the > > introduction of a new command _requires_ the use of a new > application ID. > > If this is done, then I believe that (presupposing that no > lying takes place > > during the capabilities exchange process) that it would be impossible to > > send a command that is unsupported by the peer. > > I agree with you on the above. > > > > There is high-level concern that > > > use of VSCs will great interoperability problems. > > > > If by "high-level" you mean the IESG, my understanding is that > the concerns > > have more to do with the assignation of blame for lack of > interoperability > > than the interoperability problems themselves (maybe Randy can > comment on > > this). Currently, I believe that it would not be a protocol > violation to > > add a VSC to a standard application (say, NASREQ) and claim > that the result > > is "Diameter", This is a problem, but I think that my above > proposal closes > > that loophole. > > In my personal opinion, standardizing new Diameter applications with new > command codes is OK. I don't think it bothers the IESG. The > unstandardized > command codes is the bothersome bit. But if non-standard command codes are _never_ included in standard applications, where is the problem? If I define a new app that reuses everything from accounting, say, but adds a VSC, it's still a new app... > > > > Standardization of > > > command codes are prefered. Standardization bodies using Diameter > > > extensions are strongly encouraged to standardize these. > > > > I assume that by "standardize these" you mean "standardize these in the > > IETF". Unfortunately, standardization in the IETF can be a > long process and > > as we have noticed deadlines of organizations outside the IETF > (e.g., 3GPP & > > 3GPP2) have little effect upon the speed of the process. For > example, 3GPP2 > > has been waiting for the IETF to standardize Diameter for almost 4 years > > now; would they (or 3GPP) be pleased to tie their release to what is > > essentially a nondeterministic process? > > I hear you - no reason to preach to the converted. However, do you think > that new command codes are really needed? I've heard from folks with > much more Radius experience that new Radius command codes are fairly > in frequent. Well, RADIUS doesn't really have "command codes" (the analagous construct is the "Packet Type"). While it's true that no new RADIUS Packet Types have been standardized, that fact has less to do with the lack of need for them than other factors. Several (vendor-specific, non-standard, non-interoperable) new Packet Types _have_ been defined, though, and are in widespread use today (see RFC 2882 for an overview). When you really _need_ a new command code, nothing else will substitute. > > > > > > > In summary, what is needed to the base specification is: > > > > > > a. Eliminate vendor-specific commands, but keep > > vendor-specific AVPs. > > > > > > b. Carve out an "experimental" playpen space within the > > existing command > > > space, where vendors can create experimental commands. > > > > > > c. Allow use of Application IDs in a broader set of circumstances: > > > 1. To indicate support for a set of vendor-specific > > AVPs with the 'M' > > > bit set > > > 2. To indicate support for an "experimental" command > > > > > > As a result, it will no longer be required that an > > application have a new > > > command (standard or vendor-specific) associated with it. > > > > > > Some implications of this: > > > > > > d. The CER/CEA exchange should prevent sending of > > Vendor-Specific AVPs > > > with the 'M' bit set to peers that do not support those AVPs. > > > This means > > > that the Diameter peers won't need to retry without 'M' bit > > > AVPs after an > > > "unrecognized AVP" error. > > > > > > e. Conflicts between "experimental" commands are avoided as > > long as the > > > application IDs are unique. > > > > > > f. The Application ID space needs to be partioned between > > > "applications with new 'M' bit AVPs, but no new commands" and > > > "applications with commands." Reasons for this are > > described in g. > > > > "g." discusses only accounting; since the "standard" accounting > service just > > logs stuff, the use of the 'M' bit seems uncessary. So if 3GPP > wants to be > > able to set the 'M' bit on VSAs, why? > > Let me look into this. > > > > g. Two types of generic advertisement are needed. Today we have the > > > "Relay" advertisement that implies "all applications." But we > > > also need > > > an "any AVPs" advertisement for Accounting Servers. This > > allows an > > > Accounting Server to advertise that it can accept any AVP, > > > without also > > > implying that it can handle any "experimental" command > > thrown at it, > > > which is difficult or impossible to support in practice. > > > > There is no need for a new advertisement: simply make the > > Acct-Application-Id AVP required in all accounting and > capabilities exchange > > messages, and define a value for it in the base protocol that means > > "Standard". > > That might work. > > thanks for the comments, > John > > From owner-aaa-wg@merit.edu Tue Jun 25 02:10: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 CAA23622 for ; Tue, 25 Jun 2002 02:10:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A07291249; Tue, 25 Jun 2002 02:10:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25A4A9124A; Tue, 25 Jun 2002 02:10: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 31F9191249 for ; Tue, 25 Jun 2002 02:10:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 173845DE3D; Tue, 25 Jun 2002 02:10:46 -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 8F2B45DE1F for ; Tue, 25 Jun 2002 02:10:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5P5Joi16371; Mon, 24 Jun 2002 22:19:50 -0700 Date: Mon, 24 Jun 2002 22:19:50 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: john.loughney@nokia.com, Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Well, RADIUS doesn't really have "command codes" (the analagous construct is > the "Packet Type"). While it's true that no new RADIUS Packet Types have > been standardized, that fact has less to do with the lack of need for them > than other factors. Several (vendor-specific, non-standard, > non-interoperable) new Packet Types _have_ been defined, though, and are in > widespread use today (see RFC 2882 for an overview). When you really _need_ > a new command code, nothing else will substitute. Sure. I'd say that RFC 2882 is a good example of justifiable new command codes. Still, a few new command codes in 7+ years isn't much. > > > "g." discusses only accounting; since the "standard" accounting > > service just > > > logs stuff, the use of the 'M' bit seems uncessary. So if 3GPP > > wants to be > > > able to set the 'M' bit on VSAs, why? I have assumed that the 'M' bit is set on accounting AVPs for accounting servers that drop AVPs they don't understand. That way they can know whether the AVP is critical or not. However, I have never understood why an accounting server should behave this way, rather than just writing a record to disk, in which case the 'M' bit is irrelevant. Note that even a "disk writing" accounting server cannot handle commands it doesn't support, since presumably those commands are doing something different than ACA/ACR (if they aren't, then a new command probably isn't appropriate). > > > There is no need for a new advertisement: simply make the > > > Acct-Application-Id AVP required in all accounting and > > capabilities exchange > > > messages, and define a value for it in the base protocol that means > > > "Standard". Unfortunately, there is some confusion about whether it is possible to advertise the "standard" Acct-Application-ID if a new authentication application ID is used. Also, there may be some accounting servers that can't handle any accounting AVPs, and some that can -- and it's necessary to differentiate them, no? From owner-aaa-wg@merit.edu Tue Jun 25 02:49: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 CAA24424 for ; Tue, 25 Jun 2002 02:49:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D6759124C; Tue, 25 Jun 2002 02:50:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F1519124E; Tue, 25 Jun 2002 02:50:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F3F99124C for ; Tue, 25 Jun 2002 02:50:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B0155DE1F; Tue, 25 Jun 2002 02:50:12 -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 400A75DE52 for ; Tue, 25 Jun 2002 02:50:11 -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 g5P6oeUg022412; Tue, 25 Jun 2002 08:50:40 +0200 From: "Fredrik Johansson" To: , , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Tue, 25 Jun 2002 08:50:44 +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) 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 > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Glen Zorn > Sent: den 25 juni 2002 07:00 > To: john.loughney@nokia.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > john.loughney@nokia.com [mailto:john.loughney@nokia.com] writes: > > > Hi Glen, > > > > > So is this an actual proposal, a meeting report, or the report > > of a decision > > > (ordinarily I would never suggest the last, since this is the > > IETF, but it > > > has that tone...). > > > > Sorry for the tone, it is a strong proposal. > > OK, thanks for the clarification. > > > What I mean by that, is that > > the IESG has stated that they are not comfortable with VSCs and > this needs > > to be resolved before Diameter can be Diameter can be progressed. 3GPP > > has 2 Diameter extentions, that use VSCs and so we are working on how to > > resolve the issue with as little pain to all of the parties involved. > > > > > > The main issue is that VSCs generally require understanding in an > > > > implementation. Currently, we have no way to manage communication > > > > between implementations where there is not support for VSCs that > > > > are sent by a Diameter peer. > > > > > > That depends upon how you define "manage communication". At > the risk of > > > becoming tediously repetitive, I pointed out on this list > more than two > > > weeks ago (to thundering silence) that there already exists a > > well-defined > > > method to handle unrecognized commands (vendor-specific or > > otherwise). For > > > convenience, I'll quote it here: "...if a vendor-specific > > request is sent to > > > a box that doesn't support it, the resulting answer (same > > command code for > > > easy identification) will have the E bit set and a result code of > > > DIAMETER_COMMAND_UNSUPPORTED. How much simpler (sic) can you get?". > > > > I haven't heard any feedback on this, I don't know if it is OK > > with the IESG, > > but I agree that this is simple & affective. > > Better yet, it's already in the protocol! Thanks Glen, This is something that's been discussed since the interim meeting in Santa Clara (May-01, if I'm not misstaken) With the negotiation we have in the protocol today (with the clarification Glen mentions further down) there is no way a VSC will be sent to a peer unless the one sending the command is missbehaving. It's also obvious who is at fault if a standard command code is sent with a vendor specific AVP with the 'M'-bit set is sent, it's the sender. And it's up to the sender to decide wether to try again with a modified request/response or to just realize that it could not get the service requested. > > > > > > Of course, that doesn't help to avoid sending the inappropriate > > command in the > > > first place. However, there is an easy way to fix this: > simply make the > > > relationship between application and command code reciprocal. > > Right now, I > > > believe that the creation of a new application requires the > > creation of a > > > new command code but not vice-versa please correct me if I'm > > wrong). In my > > > mind, anyway, this relationship has always been reciprocal (i.e., the > > > introduction of a new command _requires_ the use of a new > > application ID. > > > If this is done, then I believe that (presupposing that no > > lying takes place > > > during the capabilities exchange process) that it would be > impossible to > > > send a command that is unsupported by the peer. > > > > I agree with you on the above. > > > > > > There is high-level concern that > > > > use of VSCs will great interoperability problems. > > > > > > If by "high-level" you mean the IESG, my understanding is that > > the concerns > > > have more to do with the assignation of blame for lack of > > interoperability > > > than the interoperability problems themselves (maybe Randy can > > comment on > > > this). Currently, I believe that it would not be a protocol > > violation to > > > add a VSC to a standard application (say, NASREQ) and claim > > that the result > > > is "Diameter", This is a problem, but I think that my above > > proposal closes > > > that loophole. I agree, a new VSC should require a new application id so it can be negotiated. If we mandate that, I don't see what problem the IESG should have with a protocol that has nativ support for VSC and vendor specific AVPs. I would be much more concerned if the protocol didn't have it. As it is now, we have a way to handle vendor specific applications which doesn't jeopardize interoperability. /Fredrik > > > > In my personal opinion, standardizing new Diameter applications with new > > command codes is OK. I don't think it bothers the IESG. The > > unstandardized > > command codes is the bothersome bit. > > But if non-standard command codes are _never_ included in standard > applications, where is the problem? If I define a new app that reuses > everything from accounting, say, but adds a VSC, it's still a new app... > > > > > > > Standardization of > > > > command codes are prefered. Standardization bodies using Diameter > > > > extensions are strongly encouraged to standardize these. > > > > > > I assume that by "standardize these" you mean "standardize > these in the > > > IETF". Unfortunately, standardization in the IETF can be a > > long process and > > > as we have noticed deadlines of organizations outside the IETF > > (e.g., 3GPP & > > > 3GPP2) have little effect upon the speed of the process. For > > example, 3GPP2 > > > has been waiting for the IETF to standardize Diameter for > almost 4 years > > > now; would they (or 3GPP) be pleased to tie their release to what is > > > essentially a nondeterministic process? > > > > I hear you - no reason to preach to the converted. However, do > you think > > that new command codes are really needed? I've heard from folks with > > much more Radius experience that new Radius command codes are fairly > > in frequent. > > Well, RADIUS doesn't really have "command codes" (the analagous > construct is > the "Packet Type"). While it's true that no new RADIUS Packet Types have > been standardized, that fact has less to do with the lack of need for them > than other factors. Several (vendor-specific, non-standard, > non-interoperable) new Packet Types _have_ been defined, though, > and are in > widespread use today (see RFC 2882 for an overview). When you > really _need_ > a new command code, nothing else will substitute. > > > > > > > > > > > In summary, what is needed to the base specification is: > > > > > > > > a. Eliminate vendor-specific commands, but keep > > > vendor-specific AVPs. > > > > > > > > b. Carve out an "experimental" playpen space within the > > > existing command > > > > space, where vendors can create experimental commands. > > > > > > > > c. Allow use of Application IDs in a broader set of circumstances: > > > > 1. To indicate support for a set of vendor-specific > > > AVPs with the 'M' > > > > bit set > > > > 2. To indicate support for an "experimental" command > > > > > > > > As a result, it will no longer be required that an > > > application have a new > > > > command (standard or vendor-specific) associated with it. > > > > > > > > Some implications of this: > > > > > > > > d. The CER/CEA exchange should prevent sending of > > > Vendor-Specific AVPs > > > > with the 'M' bit set to peers that do not support those AVPs. > > > > This means > > > > that the Diameter peers won't need to retry without 'M' bit > > > > AVPs after an > > > > "unrecognized AVP" error. > > > > > > > > e. Conflicts between "experimental" commands are avoided as > > > long as the > > > > application IDs are unique. > > > > > > > > f. The Application ID space needs to be partioned between > > > > "applications with new 'M' bit AVPs, but no new commands" and > > > > "applications with commands." Reasons for this are > > > described in g. > > > > > > "g." discusses only accounting; since the "standard" accounting > > service just > > > logs stuff, the use of the 'M' bit seems uncessary. So if 3GPP > > wants to be > > > able to set the 'M' bit on VSAs, why? > > > > Let me look into this. > > > > > > g. Two types of generic advertisement are needed. Today we have the > > > > "Relay" advertisement that implies "all applications." But we > > > > also need > > > > an "any AVPs" advertisement for Accounting Servers. This > > > allows an > > > > Accounting Server to advertise that it can accept any AVP, > > > > without also > > > > implying that it can handle any "experimental" command > > > thrown at it, > > > > which is difficult or impossible to support in practice. > > > > > > There is no need for a new advertisement: simply make the > > > Acct-Application-Id AVP required in all accounting and > > capabilities exchange > > > messages, and define a value for it in the base protocol that means > > > "Standard". > > > > That might work. > > > > thanks for the comments, > > John > > > > > From owner-aaa-wg@merit.edu Tue Jun 25 02:54: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 CAA24512 for ; Tue, 25 Jun 2002 02:54:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82A3C9124E; Tue, 25 Jun 2002 02:55:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 543F89124F; Tue, 25 Jun 2002 02:55: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 403189124E for ; Tue, 25 Jun 2002 02:55:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 184115DE61; Tue, 25 Jun 2002 02:55:00 -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 901D65DE60 for ; Tue, 25 Jun 2002 02:54:59 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-891.cisco.com [10.21.67.123]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id XAA17810; Mon, 24 Jun 2002 23:54:49 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" Cc: , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Mon, 24 Jun 2002 23:54:33 -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 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > Well, RADIUS doesn't really have "command codes" (the analagous > construct is > > the "Packet Type"). While it's true that no new RADIUS Packet > Types have > > been standardized, that fact has less to do with the lack of > need for them > > than other factors. Several (vendor-specific, non-standard, > > non-interoperable) new Packet Types _have_ been defined, > though, and are in > > widespread use today (see RFC 2882 for an overview). When you > really _need_ > > a new command code, nothing else will substitute. > > Sure. I'd say that RFC 2882 is a good example of justifiable new command > codes. Still, a few new command codes in 7+ years isn't much. True, except that even one breaks interoperability completely. > > > > > "g." discusses only accounting; since the "standard" accounting > > > service just > > > > logs stuff, the use of the 'M' bit seems uncessary. So if 3GPP > > > wants to be > > > > able to set the 'M' bit on VSAs, why? > > I have assumed that the 'M' bit is set on accounting AVPs for accounting > servers that drop AVPs they don't understand. That way they can know > whether the AVP is critical or not. However, I have never understood why > an accounting server should behave this way, rather than just writing a > record to disk, in which case the 'M' bit is irrelevant. > > Note that even a "disk writing" accounting server cannot handle commands > it doesn't support, since presumably those commands are doing something > different than ACA/ACR (if they aren't, then a new command probably isn't > appropriate). Of course. > > > > > There is no need for a new advertisement: simply make the > > > > Acct-Application-Id AVP required in all accounting and > > > capabilities exchange > > > > messages, and define a value for it in the base protocol that means > > > > "Standard". > > Unfortunately, there is some confusion about whether it is possible to > advertise the "standard" Acct-Application-ID if a new authentication > application ID is used. Hmm. Accordin to -11, "Application Identifiers are advertised during the capabilities exchange phase (see section 5.3). For a given application, there are two different ways of advertising support. First, advertising support of the application via the Auth-Application-Id implies that the sender supports all authentication and authorization command codes, and the AVPs specified in the associated ABNFs, described in the specification. Second, advertising support of the application via the Acct-Application-Id implies that the sender supports the Accounting command codes defined in this specification, as well as the accounting AVPs defined in the application's specification." > Also, there may be some accounting servers that > can't handle any accounting AVPs, and some that can -- and it's necessary > to differentiate them, no? Sorry, but I can't parse that sentence: if an accounting server can't handle any accounting AVPs, is it still an accounting server? > > > > From owner-aaa-wg@merit.edu Tue Jun 25 03:06: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 DAA24779 for ; Tue, 25 Jun 2002 03:06:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 066D39124F; Tue, 25 Jun 2002 03:06:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8512191250; Tue, 25 Jun 2002 03:06: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 1CA559124F for ; Tue, 25 Jun 2002 03:06:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC03D5DE60; Tue, 25 Jun 2002 03:06:28 -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 4A18D5DE59 for ; Tue, 25 Jun 2002 03:06:28 -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 g5P76VUg022694; Tue, 25 Jun 2002 09:06:33 +0200 From: "Fredrik Johansson" To: "Bernard Aboba" , "Glen Zorn" Cc: , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Tue, 25 Jun 2002 09:06:37 +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 > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Bernard Aboba > Sent: den 25 juni 2002 07:20 > To: Glen Zorn > Cc: john.loughney@nokia.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > > Well, RADIUS doesn't really have "command codes" (the analagous > construct is > > the "Packet Type"). While it's true that no new RADIUS Packet > Types have > > been standardized, that fact has less to do with the lack of > need for them > > than other factors. Several (vendor-specific, non-standard, > > non-interoperable) new Packet Types _have_ been defined, > though, and are in > > widespread use today (see RFC 2882 for an overview). When you > really _need_ > > a new command code, nothing else will substitute. > > Sure. I'd say that RFC 2882 is a good example of justifiable new command > codes. Still, a few new command codes in 7+ years isn't much. > > > > > "g." discusses only accounting; since the "standard" accounting > > > service just > > > > logs stuff, the use of the 'M' bit seems uncessary. So if 3GPP > > > wants to be > > > > able to set the 'M' bit on VSAs, why? > > I have assumed that the 'M' bit is set on accounting AVPs for accounting > servers that drop AVPs they don't understand. That way they can know > whether the AVP is critical or not. However, I have never understood why > an accounting server should behave this way, rather than just writing a > record to disk, in which case the 'M' bit is irrelevant. > > Note that even a "disk writing" accounting server cannot handle commands > it doesn't support, since presumably those commands are doing something > different than ACA/ACR (if they aren't, then a new command probably isn't > appropriate). > > > > > There is no need for a new advertisement: simply make the > > > > Acct-Application-Id AVP required in all accounting and > > > capabilities exchange > > > > messages, and define a value for it in the base protocol that means > > > > "Standard". > > Unfortunately, there is some confusion about whether it is possible to > advertise the "standard" Acct-Application-ID if a new authentication > application ID is used. Also, there may be some accounting servers that > can't handle any accounting AVPs, and some that can -- and it's necessary > to differentiate them, no? I thought that the base protocol says that each new application must define it's own accounting specific avps to be sent in accounting requests and responses. See base 1.2.3 "New Diameter applications MUST define at least one Command Code, the expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY also define new AVPs. If the Diameter application has any accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see section 9.3)." I.e. it's possible to advertise support for accounting for each individual application since we have the accouting-application-id, it's even possible to advertise support for vendor specific accouting applications. Be definition, in order to call itself a diameter server one must suport the base protocol, what you then can do to differentiate the server for authentication from the ones for accounting is to set the accounting application id's in the negitiation to say wether you would like to receive accounting data or not. /Fredrik From owner-aaa-wg@merit.edu Tue Jun 25 09:13:00 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 JAA04409 for ; Tue, 25 Jun 2002 09:13:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83E1B91210; Tue, 25 Jun 2002 09:13:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53B639124D; Tue, 25 Jun 2002 09:13: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 7022791210 for ; Tue, 25 Jun 2002 09:13:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CDDA5DE5C; Tue, 25 Jun 2002 09:13:28 -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 DD51A5DE3F for ; Tue, 25 Jun 2002 09:13:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5PCMFL07559; Tue, 25 Jun 2002 05:22:15 -0700 Date: Tue, 25 Jun 2002 05:22:14 -0700 (PDT) From: Bernard Aboba To: Fredrik Johansson Cc: Glen Zorn , , Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > "New Diameter applications MUST define at least one Command Code, the > expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY > also define new AVPs. If the Diameter application has any accounting > requirements, it MUST also specify the AVPs that are to be present in > the Diameter Accounting messages (see section 9.3)." > > I.e. it's possible to advertise support for accounting for each individual > application since we have the accouting-application-id, it's even possible > to advertise support for vendor specific accouting applications. Be > definition, in order to call itself a diameter server one must suport the > base protocol, what you then can do to differentiate the server for > authentication from the ones for accounting is to set the accounting > application id's in the negitiation to say wether you would like to receive > accounting data or not. The problem is that some have interpretted the above text to mean that in order to use a new application ID, they MUST create a new Command Code, even if one wouldn't otherwise be needed. For example, if they define a new set of Vendor-Specific AVPs with the 'M' bit set, and would like to only send those AVPs to a compatible peer. This requires a new Application ID, but the above text also indicates it requires a new Command Code. This doesn't make sense. From owner-aaa-wg@merit.edu Tue Jun 25 09:17:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04642 for ; Tue, 25 Jun 2002 09:17:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5A819122F; Tue, 25 Jun 2002 09:18:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7993291236; Tue, 25 Jun 2002 09:18: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 9540D9122F for ; Tue, 25 Jun 2002 09:18:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 775325DE5E; Tue, 25 Jun 2002 09:18:13 -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 02C625DE3F for ; Tue, 25 Jun 2002 09:18:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5PCR9b07805; Tue, 25 Jun 2002 05:27:09 -0700 Date: Tue, 25 Jun 2002 05:27:09 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: john.loughney@nokia.com, Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > "Application Identifiers are advertised during the capabilities > exchange phase (see section 5.3). For a given application, there are > two different ways of advertising support. First, advertising support > of the application via the Auth-Application-Id implies that the > sender supports all authentication and authorization command codes, > and the AVPs specified in the associated ABNFs, described in the > specification. Second, advertising support of the application via the > Acct-Application-Id implies that the sender supports the Accounting > command codes defined in this specification, as well as the > accounting AVPs defined in the application's specification." > > Sorry, but I can't parse that sentence: if an accounting server can't handle > any accounting AVPs, is it still an accounting server? The text above is contradictory - it implies that Acct-Application-Ids only imply support for new accounting AVPs in the application spec, as well as the "standard" accounting command codes ("this specification"). However, elsewhere it indicates that a new application ID requires a new command code. If an accounting server can't handle non-supported AVPs with the 'M' bit set, it is still an accounting server. However, I'd claim that it is better to have a new Application ID defined (without a new command code) to enable capabilities negotiation so those 'M' AVPs are not sent, than it is to send them and get an error message back. From owner-aaa-wg@merit.edu Tue Jun 25 10:39:00 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 KAA07776 for ; Tue, 25 Jun 2002 10:39:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EBFD79124D; Tue, 25 Jun 2002 10:39:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B740791253; Tue, 25 Jun 2002 10:39:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1AC29124D for ; Tue, 25 Jun 2002 10:39:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93E4B5DE65; Tue, 25 Jun 2002 10:39:19 -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 19FEA5DE3F for ; Tue, 25 Jun 2002 10:39:19 -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 g5PEcPUg000326; Tue, 25 Jun 2002 16:38:25 +0200 From: "Fredrik Johansson" To: "Bernard Aboba" Cc: "Glen Zorn" , , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Tue, 25 Jun 2002 16:38:33 +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) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: den 25 juni 2002 14:22 > To: Fredrik Johansson > Cc: Glen Zorn; john.loughney@nokia.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > > "New Diameter applications MUST define at least one Command Code, the > > expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY > > also define new AVPs. If the Diameter application has any accounting > > requirements, it MUST also specify the AVPs that are to be present in > > the Diameter Accounting messages (see section 9.3)." > > > > I.e. it's possible to advertise support for accounting for each > individual > > application since we have the accouting-application-id, it's > even possible > > to advertise support for vendor specific accouting applications. Be > > definition, in order to call itself a diameter server one must > suport the > > base protocol, what you then can do to differentiate the server for > > authentication from the ones for accounting is to set the accounting > > application id's in the negitiation to say wether you would > like to receive > > accounting data or not. > > The problem is that some have interpretted the above text to mean that > in order to use a new application ID, they MUST create a new Command > Code, even if one wouldn't otherwise be needed. I can't realy see what you mean, from the above text I believe it's obvious that a command code is required when a new application id is defined. On the other hand, if one can coupe with just adding VSAs no an existing command code, no application id is required. For example, if they > define a new set of Vendor-Specific AVPs with the 'M' bit set, and would > like to only send those AVPs to a compatible peer. This requires a new > Application ID, but the above text also indicates it requires a new > Command Code. This doesn't make sense. > Do you mean that it doesn't make sence that you can't negotiate to whom you may send VSAs? /fredrik From owner-aaa-wg@merit.edu Tue Jun 25 10:58: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 KAA08917 for ; Tue, 25 Jun 2002 10:58:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7911D91253; Tue, 25 Jun 2002 10:59:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 449A291254; Tue, 25 Jun 2002 10:59: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 42D2691253 for ; Tue, 25 Jun 2002 10:59:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2467F5DE48; Tue, 25 Jun 2002 10:59: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 B20015DE3F for ; Tue, 25 Jun 2002 10:59:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5PE7xe13315; Tue, 25 Jun 2002 07:07:59 -0700 Date: Tue, 25 Jun 2002 07:07:59 -0700 (PDT) From: Bernard Aboba To: Fredrik Johansson Cc: Glen Zorn , , Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Do you mean that it doesn't make sense that you can't negotiate to whom > you may send VSAs? Yes. The inability to know whether a peer supported VSAs was the supposed limitation of RADIUS that Diameter capabilities negotiation was supposed to fix. And vendors do appear to want to fix this -- since they're using Application IDs (and adding unnecessary command codes) in order to address the issue. From owner-aaa-wg@merit.edu Tue Jun 25 11:07:48 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 LAA09452 for ; Tue, 25 Jun 2002 11:07:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7673391254; Tue, 25 Jun 2002 11:08:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43E9591255; Tue, 25 Jun 2002 11:08: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 3400D91254 for ; Tue, 25 Jun 2002 11:08:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19C3E5DE65; Tue, 25 Jun 2002 11:08:16 -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 6281E5DE3F for ; Tue, 25 Jun 2002 11:08:15 -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 g5PF8PUg001101; Tue, 25 Jun 2002 17:08:25 +0200 From: "Fredrik Johansson" To: "Bernard Aboba" Cc: "Glen Zorn" , , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Tue, 25 Jun 2002 17:08:33 +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) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I can agree that it's a nice to have feature, but awfully hard to get. E.g. it's hard to advertise support for Vendor A's VSA within the mobile ip application without saying that also all future VSA's from vendor A within mobile ip is also supported. but if someone can come up with a easy way of differentiate the VSA's available today from the ones defined in the future, I'm all for it. Perhaps having version numbers on the VSA within a specific application, then one can say in the negotiation that I support vendor A's mobile ip VSA up to version nr X. Hmm, gets complicated /fredrik > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: den 25 juni 2002 16:08 > To: Fredrik Johansson > Cc: Glen Zorn; john.loughney@nokia.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > > Do you mean that it doesn't make sense that you can't negotiate to whom > > you may send VSAs? > > Yes. The inability to know whether a peer supported VSAs was the supposed > limitation of RADIUS that Diameter capabilities negotiation was supposed > to fix. And vendors do appear to want to fix this -- since they're using > Application IDs (and adding unnecessary command codes) in order to address > the issue. From owner-aaa-wg@merit.edu Tue Jun 25 11:21: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 LAA10188 for ; Tue, 25 Jun 2002 11:21:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F317B91255; Tue, 25 Jun 2002 11:21:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8C6F91256; Tue, 25 Jun 2002 11:21:57 -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 AA91791255 for ; Tue, 25 Jun 2002 11:21:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94BB25DE6C; Tue, 25 Jun 2002 11:21:56 -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 BEF735DE3F for ; Tue, 25 Jun 2002 11:21:55 -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 g5PFMNi29354 for ; Tue, 25 Jun 2002 18:22:23 +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 ; Tue, 25 Jun 2002 18:21:51 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 25 Jun 2002 18:21:51 +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]: Vendor Command Code resolution Date: Tue, 25 Jun 2002 18:21:50 +0300 Message-ID: <07A6D72550C5E0459DE676439EE53846E32BB3@esebe012.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIcWi7TpVr1UBUiRWalKz5HPYbLZQAAJvcw From: To: X-OriginalArrivalTime: 25 Jun 2002 15:21:51.0760 (UTC) FILETIME=[080F8900:01C21C5C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA10188 Fredrik Johansson wrote: > I can agree that it's a nice to have feature, but awfully > hard to get. E.g. it's hard to advertise support for Vendor A's VSA > within the mobile ip application without saying that also all future > VSA's from vendor A within mobile ip is also supported. I think the vendor is responsible for specifying the application/extension so that it is clear what VSAs and/or VSCs are included. If new VSAs/VSCs are added the application-id should change too. > but if someone can come up with a easy way of differentiate the VSA's > available today from the ones defined in the future, I'm all for it. > Perhaps having version numbers on the VSA within a specific > application, then one can say in the negotiation that I support vendor A's > mobile ip VSA up to version nr X. Hmm, gets complicated My understanding has been that if the "version" of the application changes it means new application-id is assigned. And if the "version" of AVP changes it means new AVP-code is assigned. BR, Mikko From owner-aaa-wg@merit.edu Tue Jun 25 14:14: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 OAA19805 for ; Tue, 25 Jun 2002 14:14:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B59B09125A; Tue, 25 Jun 2002 14:14:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8718C9125C; Tue, 25 Jun 2002 14:14: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 857119125A for ; Tue, 25 Jun 2002 14:14:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A4455DD9A; Tue, 25 Jun 2002 14:14:24 -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 1C8F35DD91 for ; Tue, 25 Jun 2002 14:14:24 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-891.cisco.com [10.21.67.123]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA04813; Tue, 25 Jun 2002 11:14:13 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Jacques Caron" , Cc: Subject: [AAA-WG]: RE: draft-ietf-aaa-eap-00.txt Date: Tue, 25 Jun 2002 11:14:08 -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 Importance: Normal In-Reply-To: <5.1.0.14.0.20020625135854.03ceb6d8@195.134.198.25> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jacques Caron [mailto:Jacques.Caron@IPsector.com] writes: > Hi, > > Just saw your draft, and even though I haven't read it thoroughly yet, I > have to admit I'm puzzled... Isn't EAP authentication part of the > "normal" > NASREQ application of Diameter? Not any more :-). EAP support will not be present in the next rev of the NASREQ doc; this doc is basically a placeholder while the EAP gurus figure out how to fix it. > What's the purpose of this application? I > would understand if the goal was to make it "cleaner" and to get rid of > legacy NASREQ/RADIUS stuff, but I guess this should then be > stated/explained somewhere in the draft, shouldn't it? And it > also creates > quite a bit of duplication. I hate duplication :-) > > Puzzled... > > Jacques. > > > From owner-aaa-wg@merit.edu Wed Jun 26 18:50:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14441 for ; Wed, 26 Jun 2002 18:50:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89457912D1; Wed, 26 Jun 2002 18:50:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 298C8912D8; Wed, 26 Jun 2002 18:50:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B38D912D1 for ; Wed, 26 Jun 2002 18:50:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 50EC25DDF0; Wed, 26 Jun 2002 18:50:08 -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 1F61D5DD9A for ; Wed, 26 Jun 2002 18:50:08 -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 g5QMo7i20279; Wed, 26 Jun 2002 17:50:07 -0500 (CDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g5QMo7K20039; Wed, 26 Jun 2002 17:50:07 -0500 (CDT) Received: from ericsson.com (T21ICEMAN [138.85.159.128]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NWAD53J0; Wed, 26 Jun 2002 17:50:07 -0500 Message-ID: <3D1A4422.1F5D8B42@ericsson.com> Date: Wed, 26 Jun 2002 15:45:54 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Vendor Command Code resolution References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E68@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, All, Okay, so if the conclusion with IESG is that we cannot keep the VSCs and should instead have an experimental command code space, that to me is still perfectly find and should cause very little modification to the base. Thus, replacing VSCs with a "experimental" command code space, clarifying the relation between creating new command codes and applications (which to most parts is already in place) and adding support for applications with or without mandatory VSAs. Please see further comments embedded. /Tony john.loughney@nokia.com wrote: > Hi all, > > Here is a summary of the direction taken during a discussion with > 3GPP. > > The main issue is that VSCs generally require understanding in an > implementation. Currently, we have no way to manage communication > between implementations where there is not support for VSCs that > are sent by a Diameter peer. There is high-level concern that > use of VSCs will great interoperability problems. Standardization of > command codes are prefered. Standardization bodies using Diameter > extensions are strongly encouraged to standardize these. > > In summary, what is needed to the base specification is: > > a. Eliminate vendor-specific commands, but keep vendor-specific AVPs. > > > b. Carve out an "experimental" playpen space within the existing command > space, where vendors can create experimental commands. So, with bullet a and b, we have replaced the VSCs with an experimental command code space. So, for this a small section needs to be added that defines the experimental command code space. > > > c. Allow use of Application IDs in a broader set of circumstances: > 1. To indicate support for a set of vendor-specific AVPs with the 'M' > bit set > 2. To indicate support for an "experimental" command > > As a result, it will no longer be required that an application have a new > command (standard or vendor-specific) associated with it. However, as been mention on the list, to create and use a new experimental command code you MUST also create a new application in which the new command code will be run. Thus, make the relationship between application and command code reciprocal. > > > Some implications of this: > > d. The CER/CEA exchange should prevent sending of Vendor-Specific AVPs > with the 'M' bit set to peers that do not support those AVPs. This means > that the Diameter peers won't need to retry without 'M' bit AVPs after an > "unrecognized AVP" error. > > e. Conflicts between "experimental" commands are avoided as long as the > application IDs are unique. Since, this will be just a pool of experimental command codes, which means that the same experimental command code may be reused in several vendor specific application, we need application IDs and the Vendor ID in the Diameter header (as of today, i.e. let be as is) to guarantee avoiding conflict. > > > f. The Application ID space needs to be partioned between > "applications with new 'M' bit AVPs, but no new commands" and > "applications with commands." Reasons for this are described in g. > > g. Two types of generic advertisement are needed. Today we have the > "Relay" advertisement that implies "all applications." But we also need > an "any AVPs" advertisement for Accounting Servers. This allows an > Accounting Server to advertise that it can accept any AVP, without also > implying that it can handle any "experimental" command thrown at it, > which is difficult or impossible to support in practice. > > Note that if this were not done then we would undermine capabilities > negotiation, since peers could advertise capabilities they didn't really > support. > > best regards, > John > > PS - thanks to Bernard who wrote down the proposal from our conference call. From owner-aaa-wg@merit.edu Wed Jun 26 20:22:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16745 for ; Wed, 26 Jun 2002 20:22:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D4FA9122A; Wed, 26 Jun 2002 20:23:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFB8791232; Wed, 26 Jun 2002 20:23: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 F1FB79122A for ; Wed, 26 Jun 2002 20:23:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8FD35DE6A; Wed, 26 Jun 2002 20:23:10 -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 52AA25DD8E for ; Wed, 26 Jun 2002 20:23:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5QNW3925200; Wed, 26 Jun 2002 16:32:04 -0700 Date: Wed, 26 Jun 2002 16:32:03 -0700 (PDT) From: Bernard Aboba To: Tony Johansson Cc: john.loughney@nokia.com, Subject: Re: [AAA-WG]: Vendor Command Code resolution In-Reply-To: <3D1A4422.1F5D8B42@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Comments below. > So, with bullet a and b, we have replaced the VSCs with an experimental command > code space. So, for this a small section needs to be added that defines the > experimental command code space. Yes. This is a portion of the existing command code space, no? The question is how much space is required. > > c. Allow use of Application IDs in a broader set of circumstances: > > 1. To indicate support for a set of vendor-specific AVPs with the 'M' > > bit set > > 2. To indicate support for an "experimental" command > > > > As a result, it will no longer be required that an application have a new > > command (standard or vendor-specific) associated with it. > > However, as been mention on the list, to create and use a new experimental > command code you MUST also create a new application in which the new command > code will be run. Thus, make the relationship between application and command > code reciprocal. Yes. New command codes (experimental or not) require a new application id. However, I'd also argue that a new application ID can also be used *without* a new command code (for example, when a bunch of new AVPs with the 'M' bit set are added to existing commands). > > Some implications of this: > > > > d. The CER/CEA exchange should prevent sending of Vendor-Specific AVPs > > with the 'M' bit set to peers that do not support those AVPs. This means > > that the Diameter peers won't need to retry without 'M' bit AVPs after an > > "unrecognized AVP" error. > > > > e. Conflicts between "experimental" commands are avoided as long as the > > application IDs are unique. > > Since, this will be just a pool of experimental command codes, which means that > the same experimental command code may be reused in several vendor specific > application, we need application IDs and the Vendor ID in the Diameter header > (as of today, i.e. let be as is) to guarantee avoiding conflict. Yes. > > g. Two types of generic advertisement are needed. Today we have the > > "Relay" advertisement that implies "all applications." But we also need > > an "any AVPs" advertisement for Accounting Servers. This allows an > > Accounting Server to advertise that it can accept any AVP, without also > > implying that it can handle any "experimental" command thrown at it, > > which is difficult or impossible to support in practice. From owner-aaa-wg@merit.edu Wed Jun 26 21:51: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 VAA18900 for ; Wed, 26 Jun 2002 21:51:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50D2C912D9; Wed, 26 Jun 2002 21:52:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13F7E912DB; Wed, 26 Jun 2002 21:52: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 E20CD912D9 for ; Wed, 26 Jun 2002 21:52:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C91245DE88; Wed, 26 Jun 2002 21:52:07 -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 548465DE84 for ; Wed, 26 Jun 2002 21:52:07 -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 g5R1p6l00271; Wed, 26 Jun 2002 20:51:46 -0500 (CDT) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g5R1p6a23671; Wed, 26 Jun 2002 20:51:06 -0500 (CDT) Received: from ericsson.com (T21ICEMAN [138.85.159.128]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NWAD589R; Wed, 26 Jun 2002 20:51:05 -0500 Message-ID: <3D1A6E8D.F560E166@ericsson.com> Date: Wed, 26 Jun 2002 18:46:53 -0700 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: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Vendor Command Code resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > Yes. New command codes (experimental or not) require a new application id. > However, I'd also argue that a new application ID can also be used > *without* a new command code (for example, when a bunch of new AVPs with > the 'M' bit set are added to existing commands). Agree. From owner-aaa-wg@merit.edu Thu Jun 27 00:36: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 AAA22621 for ; Thu, 27 Jun 2002 00:36:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A590F912E0; Thu, 27 Jun 2002 00:35:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CB9B912E3; Thu, 27 Jun 2002 00:35: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 0EF5D912E0 for ; Thu, 27 Jun 2002 00:35:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F00225DE93; Thu, 27 Jun 2002 00:35:20 -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 A27585DE84 for ; Thu, 27 Jun 2002 00:35:20 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-361.cisco.com [10.21.65.105]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA22580; Wed, 26 Jun 2002 21:35:09 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Tony Johansson" , "Bernard Aboba" Cc: , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Wed, 26 Jun 2002 21:35:01 -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 Importance: Normal In-Reply-To: <3D1A6E8D.F560E166@ericsson.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson [mailto:tony.johansson@ericsson.com] writes: > Bernard Aboba wrote: > > > > > Yes. New command codes (experimental or not) require a new > application id. > > However, I'd also argue that a new application ID can also be used > > *without* a new command code (for example, when a bunch of new AVPs with > > the 'M' bit set are added to existing commands). The restriction that a new application must include a new command code resulted from conversations with the IESG (a _long_ time ago). I believe that the concern was that there would be a flood of new "applications" which simply used existing AVPs in some non-standard way, or were created to get around restrictions in the standard protocol that for whatever reason were viewed as unpalatable. Since it seems to me that that is exactly what Bernard is suggesting, maybe they were right. On the other hand, it's a new IESG, so maybe they won't mind... > > Agree. > > > From owner-aaa-wg@merit.edu Thu Jun 27 02:40: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 CAA03731 for ; Thu, 27 Jun 2002 02:40:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80B7B91235; Thu, 27 Jun 2002 02:41:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 508DB912E3; Thu, 27 Jun 2002 02:41:26 -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 60C9B91235 for ; Thu, 27 Jun 2002 02:41:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4917A5DE7B; Thu, 27 Jun 2002 02:41:25 -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 154315DD8E for ; Thu, 27 Jun 2002 02:41:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5R5ngS13152; Wed, 26 Jun 2002 22:49:42 -0700 Date: Wed, 26 Jun 2002 22:49:42 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: Tony Johansson , , Subject: RE: [AAA-WG]: Vendor Command Code resolution 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 restriction that a new application must include a new command code > resulted from conversations with the IESG (a _long_ time ago). I believe > that the concern was that there would be a flood of new "applications" which > simply used existing AVPs in some non-standard way, or were created to get Can you give an example of this? If you are merely adding some optional AVPs, as long as the ABNF isn't violated, I wouldn't think that a new application ID is required. However, if vendor-specific AVPs with the 'M' bit set are included, then you might as well know whether the peer will be able to handle them before sending them, no? This doesn't affect interoperability because presumably the 'M' bit AVPs wouldn't be supported on the peer anyway. From owner-aaa-wg@merit.edu Thu Jun 27 02:47: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 CAA03858 for ; Thu, 27 Jun 2002 02:47:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 133BC912E3; Thu, 27 Jun 2002 02:47:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2AA9912E4; Thu, 27 Jun 2002 02:47: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 9AD0C912E3 for ; Thu, 27 Jun 2002 02:47:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C5CF5DD9B; Thu, 27 Jun 2002 02:47:18 -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 361715DD8E for ; Thu, 27 Jun 2002 02:46:59 -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 g5R6jwUg002561; Thu, 27 Jun 2002 08:45:58 +0200 From: "Fredrik Johansson" To: "Bernard Aboba" , "Glen Zorn" Cc: "Tony Johansson" , , Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 08:46:09 +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) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: 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 > Bernard Aboba > Sent: den 27 juni 2002 07:50 > To: Glen Zorn > Cc: Tony Johansson; john.loughney@nokia.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > > The restriction that a new application must include a new command code > > resulted from conversations with the IESG (a _long_ time ago). > I believe > > that the concern was that there would be a flood of new > "applications" which > > simply used existing AVPs in some non-standard way, or were > created to get > > Can you give an example of this? If you are merely adding some optional > AVPs, as long as the ABNF isn't violated, I wouldn't think that a new > application ID is required. However, if vendor-specific AVPs with the 'M' > bit set are included, then you might as well know whether the peer will be > able to handle them before sending them, no? This doesn't affect > interoperability because presumably the 'M' bit AVPs wouldn't be supported > on the peer anyway. But does this realy help, the capability negotiation is not end-to-end anyway. in many cases when adding VSA they are intended for the end node, so what does it help to know what the next hop can do? /fredrik From owner-aaa-wg@merit.edu Thu Jun 27 02:50: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 CAA03927 for ; Thu, 27 Jun 2002 02:50:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBBF7912E4; Thu, 27 Jun 2002 02:50:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94FC2912E5; Thu, 27 Jun 2002 02:50: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 8F654912E4 for ; Thu, 27 Jun 2002 02:50:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A56D5DD9B; Thu, 27 Jun 2002 02:50:30 -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 A52855DD8E for ; Thu, 27 Jun 2002 02:50:29 -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 g5R6ovi15554 for ; Thu, 27 Jun 2002 09:50:57 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Jun 2002 09:50:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 09:50: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: [AAA-WG]: Vendor ID Date: Thu, 27 Jun 2002 09:50:24 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65568@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Base Updated section 1.2 Thread-Index: AcIS6l9G1LLFnIk5S0SOaGV62iWRfAIi2HjwAIwsYFA= From: To: X-OriginalArrivalTime: 27 Jun 2002 06:50:27.0033 (UTC) FILETIME=[EB5D4490:01C21DA6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA03927 In section 3 Diameter Header There is the Vendor-ID field: 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" [ASSIGNNO] 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 vendor's vendor-specific command, nor with future IETF applications. All vendor-specific Diameter commands require Informational RFCs documenting the command unless for Private Use as described in Section 11.2.1. My feeling is that should be updated to this: In the event that the Command-Code field contains an experimental command, the four-octet Vendor-ID field contains the IANA assigned "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value. If the Command-Code field contains an IETF standard Command, the Vendor-ID field MUST be set to zero (0). Any vendor using an experimental Diameter command MUST use their own Vendor-ID. John From owner-aaa-wg@merit.edu Thu Jun 27 02:53: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 CAA03996 for ; Thu, 27 Jun 2002 02:53:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A8AD912E5; Thu, 27 Jun 2002 02:53:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17CE2912E6; Thu, 27 Jun 2002 02:53:46 -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 14922912E5 for ; Thu, 27 Jun 2002 02:53:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F06A55DE7B; Thu, 27 Jun 2002 02:53:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (unknown [147.28.4.2]) by segue.merit.edu (Postfix) with ESMTP id 7795D5DD8E for ; Thu, 27 Jun 2002 02:53:44 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 4.05) id 17NSz1-0009Df-00; Wed, 26 Jun 2002 23:42:23 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Vendor Command Code resolution References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E68@esebe004.NOE.Nokia.com> <3D1A4422.1F5D8B42@ericsson.com> Message-Id: Date: Wed, 26 Jun 2002 23:42:23 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Okay, so if the conclusion with IESG is that we cannot keep the VSCs and > should instead have an experimental command code space ^ temmporary that will go away in a year or so. it's just a kindness to help release 5 randy From owner-aaa-wg@merit.edu Thu Jun 27 02:55:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04042 for ; Thu, 27 Jun 2002 02:55:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8A7A6912E6; Thu, 27 Jun 2002 02:55:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55B74912E7; Thu, 27 Jun 2002 02:55:50 -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 52338912E6 for ; Thu, 27 Jun 2002 02:55:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F61E5DE96; Thu, 27 Jun 2002 02:55:49 -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 9A5485DD8E for ; Thu, 27 Jun 2002 02:55:48 -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 g5R6uGi19241 for ; Thu, 27 Jun 2002 09:56:16 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Jun 2002 09:55:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 09:55:47 +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]: Vendor-Specific-Application-Id AVP Date: Thu, 27 Jun 2002 09:55:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65569@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Base Updated section 1.2 Thread-Index: AcIS6l9G1LLFnIk5S0SOaGV62iWRfAIi2HjwAIxrugA= From: To: X-OriginalArrivalTime: 27 Jun 2002 06:55:47.0374 (UTC) FILETIME=[AA4D6CE0:01C21DA7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA04042 6.11 Vendor-Specific-Application-Id AVP This AVP MUST also be present in all vendor-specific commands defined in the vendor-specific application. change to: From owner-aaa-wg@merit.edu Thu Jun 27 03:00: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 DAA04167 for ; Thu, 27 Jun 2002 03:00:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42EB5912E8; Thu, 27 Jun 2002 03:01:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10E0E912EA; Thu, 27 Jun 2002 03:01: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 F045D912E8 for ; Thu, 27 Jun 2002 03:01:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA4CD5DE8E; Thu, 27 Jun 2002 03:01:04 -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 9F3715DD8E for ; Thu, 27 Jun 2002 03:01:01 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5R68iY14228; Wed, 26 Jun 2002 23:08:44 -0700 Date: Wed, 26 Jun 2002 23:08:44 -0700 (PDT) From: Bernard Aboba To: Fredrik Johansson Cc: Glen Zorn , Tony Johansson , , Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > But does this realy help, the capability negotiation is not end-to-end > anyway. in many cases when adding VSA they are intended for the end node, so > what does it help to know what the next hop can do? The next hop is either a relay (in which case it will pass everything) or it is a proxy that needs to understand semantics. If it needs to understand semantics then it will need to understand the 'M' bit AVPs, too, no? If it is a relay then based on the capabilities negotiation, it can look for a downstream server with the capabilities supported by the upstream NAS. So while Diameter supports hop-by-hop capabilities negotiation, it is also capable of ensuring compatible capabilities along the path. From owner-aaa-wg@merit.edu Thu Jun 27 03:03: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 DAA04272 for ; Thu, 27 Jun 2002 03:03:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF2FC912E7; Thu, 27 Jun 2002 03:02:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 786C5912E9; Thu, 27 Jun 2002 03:02: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 E7201912E7 for ; Thu, 27 Jun 2002 03:02:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D133D5DE8E; Thu, 27 Jun 2002 03:02:09 -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 31C875DD8E for ; Thu, 27 Jun 2002 03:02:09 -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 g5R70id28384 for ; Thu, 27 Jun 2002 10:00:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Jun 2002 10:02: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, 27 Jun 2002 10:02:07 +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]: Experimental Command Codes Date: Thu, 27 Jun 2002 10:02:01 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6556A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Base Updated section 1.2 Thread-Index: AcIS6l9G1LLFnIk5S0SOaGV62iWRfAIi2HjwAIyM4CA= From: To: X-OriginalArrivalTime: 27 Jun 2002 07:02:07.0251 (UTC) FILETIME=[8CBA0E30:01C21DA8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA04272 Hi all, I am currently editing the text of the document, according to the resolution for vendor-specific command codes becoming experimental command codes. In section 11.2.1 Command Codes, I will add text explaning what an experimental command code is, what its purpose is, what its limitations are, etc. I will submit this later today. However, there are number of places where the text references vendor-specific command codes. I am currently fixing this text, changing the reference to vendor-specific to experimental, and adding a (see section 11.2.1 for information and limitations on experimental command codes). This is needed, because if someone does ever use an experimental command, we want to ensure that there is a sufficient 'fire wall' around it, so the experimental command will not cause any troubles to anyone else. Please keep that in mind when you comment on the next several mails which will follow. thanks, John From owner-aaa-wg@merit.edu Thu Jun 27 03:23:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04568 for ; Thu, 27 Jun 2002 03:23:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76891912EB; Thu, 27 Jun 2002 03:24:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 313DF912EC; Thu, 27 Jun 2002 03:24: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 13A6F912EB for ; Thu, 27 Jun 2002 03:24:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E33265DE96; Thu, 27 Jun 2002 03:24:22 -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 495A05DD8E for ; Thu, 27 Jun 2002 03:24:22 -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 g5R7Oni11577 for ; Thu, 27 Jun 2002 10:24:49 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 10:24:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 10:24:21 +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]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 10:24:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6556C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIb7V5CCr1mrjieQEacUPG34Ai/mABvik+Q From: To: , X-OriginalArrivalTime: 27 Jun 2002 07:24:21.0146 (UTC) FILETIME=[A7CA47A0:01C21DAB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA04568 Hi Glenn, > That depends upon how you define "manage communication". At the risk of > becoming tediously repetitive, I pointed out on this list more than two > weeks ago (to thundering silence) that there already exists a well-defined > method to handle unrecognized commands (vendor-specific or otherwise). For > convenience, I'll quote it here: "...if a vendor-specific request is sent to > a box that doesn't support it, the resulting answer (same command code for > easy identification) will have the E bit set and a result code of > DIAMETER_COMMAND_UNSUPPORTED. How much simpler (sic) can you get?". I've at least added the following text, based upon your suggestion: DIAMETER_COMMAND_UNSUPPORTED 3001 The Request contained a Command-Code that the receiver did not recognize or support. This MUST be used when when a Diameter node receives an experimental command that it does not understand. John From owner-aaa-wg@merit.edu Thu Jun 27 03:48: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 DAA04997 for ; Thu, 27 Jun 2002 03:48:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA1B5912EC; Thu, 27 Jun 2002 03:48:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81482912ED; Thu, 27 Jun 2002 03:48:50 -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 65652912EC for ; Thu, 27 Jun 2002 03:48:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 560C25DD9D; Thu, 27 Jun 2002 03:48:49 -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 7D9DE5DD8E for ; Thu, 27 Jun 2002 03:48:48 -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 g5R7lNd21183 for ; Thu, 27 Jun 2002 10:47:23 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 10:48:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 10:48:47 +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]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 10:48:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6556E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIcShg44f4O5BZ3TwCqQYfwU9HPuwBZNiyA From: To: , Cc: , X-OriginalArrivalTime: 27 Jun 2002 07:48:47.0219 (UTC) FILETIME=[11A34430:01C21DAF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA04997 Hi Bernard, > The problem is that some have interpretted the above text to mean that > in order to use a new application ID, they MUST create a new Command > Code, even if one wouldn't otherwise be needed. For example, if they > define a new set of Vendor-Specific AVPs with the 'M' bit > set, and would > like to only send those AVPs to a compatible peer. This requires a new > Application ID, but the above text also indicates it requires a new > Command Code. This doesn't make sense. I have modified the text to state: Note that the creation of a new application should be viewed as a last resort. New Diameter applications MUST define one Command Code or set of mandatory AVPs. The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see section 3.2). A new application MAY also define new AVPs. If the Diameter application has any accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see section 9.3). John From owner-aaa-wg@merit.edu Thu Jun 27 03:56:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05235 for ; Thu, 27 Jun 2002 03:56:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 74FD4912ED; Thu, 27 Jun 2002 03:57:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4048D912EE; Thu, 27 Jun 2002 03:57:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32D66912ED for ; Thu, 27 Jun 2002 03:56:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 179085DECB; Thu, 27 Jun 2002 03:56:59 -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 703485DEB0 for ; Thu, 27 Jun 2002 03:56:58 -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 g5R7tXd25151 for ; Thu, 27 Jun 2002 10:55:33 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 10:56:57 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 10:56:57 +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]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 10:56:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E7D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIdY9To8LLKdXsPSyOrVpY7c40wAAASUkaA From: To: Cc: X-OriginalArrivalTime: 27 Jun 2002 07:56:57.0298 (UTC) FILETIME=[35BF6320:01C21DB0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA05235 Hi Tony, > > b. Carve out an "experimental" playpen space within the > existing command > > space, where vendors can create experimental commands. > > So, with bullet a and b, we have replaced the VSCs with an experimental command > code space. So, for this a small section needs to be added that defines the > experimental command code space. Yup, that is being done. > > c. Allow use of Application IDs in a broader set of circumstances: > > 1. To indicate support for a set of vendor-specific AVPs with the 'M' > > bit set > > 2. To indicate support for an "experimental" command > > > > As a result, it will no longer be required that an application have a new > > command (standard or vendor-specific) associated with it. > > However, as been mention on the list, to create and use a new experimental > command code you MUST also create a new application in which the new command > code will be run. Thus, make the relationship between application and command > code reciprocal. I have modified the text, so I think that the above is covered. > > Some implications of this: > > > > d. The CER/CEA exchange should prevent sending of > Vendor-Specific AVPs > > with the 'M' bit set to peers that do not support those > AVPs. This means > > that the Diameter peers won't need to retry without 'M' > bit AVPs after an > > "unrecognized AVP" error. > > > > e. Conflicts between "experimental" commands are avoided as > long as the > > application IDs are unique. > > Since, this will be just a pool of experimental command codes, which means that > the same experimental command code may be reused in several vendor specific > application, we need application IDs and the Vendor ID in the Diameter header > (as of today, i.e. let be as is) to guarantee avoiding conflict. I see your point, but I am not sure we want to do this. Changing the header to support a limited, temporary value is not smart. Further more, the experimental code will contain an Application ID. John From owner-aaa-wg@merit.edu Thu Jun 27 03:58: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 DAA05307 for ; Thu, 27 Jun 2002 03:58:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 298E5912EE; Thu, 27 Jun 2002 03:58:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8EEB912EF; Thu, 27 Jun 2002 03:58: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 DF993912EE for ; Thu, 27 Jun 2002 03:58:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB5AF5DED4; Thu, 27 Jun 2002 03:58:35 -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 2E89B5DEB0 for ; Thu, 27 Jun 2002 03:58:35 -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 g5R80OW00531 for ; Thu, 27 Jun 2002 11:00:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 10:58:33 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 10:58: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-8859-1" Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 10:58:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65570@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIdcN6tGu2V9DR6SLmWKR5fBwtjeQAP3LBQ From: To: , Cc: X-OriginalArrivalTime: 27 Jun 2002 07:58:33.0871 (UTC) FILETIME=[6F4F41F0:01C21DB0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA05307 Hi Bernard, > > Since, this will be just a pool of experimental command codes, which means that > > the same experimental command code may be reused in several vendor specific > > application, we need application IDs and the Vendor ID in the Diameter header > > (as of today, i.e. let be as is) to guarantee avoiding conflict. > > Yes. Actually, if the experimental command code contains an application id, isn't that enough? It might not be elegant, but it works. John From owner-aaa-wg@merit.edu Thu Jun 27 04:09: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 EAA05672 for ; Thu, 27 Jun 2002 04:09:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79686912EF; Thu, 27 Jun 2002 04:09:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46B4D912F0; Thu, 27 Jun 2002 04:09: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 452DF912EF for ; Thu, 27 Jun 2002 04:09:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 216355DE9A; Thu, 27 Jun 2002 04:09:52 -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 4684E5DD8E for ; Thu, 27 Jun 2002 04:09:51 -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 g5R8BeW06900 for ; Thu, 27 Jun 2002 11:11:40 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 11:09:50 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 11:09:50 +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]: Base Updated section 1.2 Date: Thu, 27 Jun 2002 11:09:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65573@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Base Updated section 1.2 Thread-Index: AcIS6l9G1LLFnIk5S0SOaGV62iWRfAKx5gOg From: To: Cc: X-OriginalArrivalTime: 27 Jun 2002 08:09:50.0303 (UTC) FILETIME=[027E96F0:01C21DB2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA05672 Hi Pete, > My opinion is that the final sentence of each of these sections should > read: > > Every Diameter [authentication,accounting] application MUST have an > IANA assigned Application Identifier, or a vendor specific > Application Identifier. Good catch, I have fixed this. thanks, John > Much of the discussion recently has focused on vendor-specific > *commands* inside standard applications, but I want to make sure we > retain the ability to define new vendor-specific *applications* as > well. Note that I do not think there are any interoperability > concerns here, because both sides must explicitly indicate support for > a vendor-specific application before any of the commands belonging to > the application can be sent. These applications never constitute > "changes" or "modifications" to the Diameter base protocol or to any > standard application. Would that be acceptable to the IESG? > > -Pete > > From owner-aaa-wg@merit.edu Thu Jun 27 04:58:48 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 EAA06761 for ; Thu, 27 Jun 2002 04:58:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1967D912F0; Thu, 27 Jun 2002 04:57:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9518912F2; Thu, 27 Jun 2002 04:57: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 DE1ED912F0 for ; Thu, 27 Jun 2002 04:57:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE5645DEA0; Thu, 27 Jun 2002 04:57:26 -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 729FD5DD8E for ; Thu, 27 Jun 2002 04:57:25 -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 QAA04127 for ; Thu, 27 Jun 2002 16:53:50 +0800 (CST) Received: from PennyGuo ([202.38.197.70]) by letterbox.scut.edu.cn (8.12.2/8.9.3) with SMTP id g5R8iDUB001868 for ; Thu, 27 Jun 2002 16:44:14 +0800 (CST) Message-Id: <200206270844.g5R8iDUB001868@letterbox.scut.edu.cn> Date: Thu, 27 Jun 2002 16:56:9 +0800 From: Penny To: "aaa-wg@merit.edu" Subject: [AAA-WG]: Who is responsible for money deduction X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====002_Dragon427667882024_=====" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --=====002_Dragon427667882024_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RnJvbSBSRkMgMjk3NSAoMS4zIEFjY291bnRpbmcgbWFuYWdlbWVudCBhcmNoaXRlY3R1cmUpLCBi aWxsaW5nIHNlcnZlciAiIGhhbmRsZXMgcmF0aW5nIGFuZCBpbnZvaWNlIGdlbmVyYXRpb24sIGJ1 dCBtYXkgYWxzbyBjYXJyeSBvdXQgYXVkaXRpbmcsIGNvc3QgYWxsb2NhdGlvbiwgdHJlbmQgYW5h bHlzaXMgb3IgY2FwYWNpdHkgICBwbGFubmluZyBmdW5jdGlvbnMuICIgSSBhbSBjb25mdXNlZCBi eSB0aGlzIHNlbnRlbnNlLCBpcyBiaWxsaW5nIHNlcnZlciByZXNwb25zaWJsZSBmb3IgbW9uZXkg ZGVkdWN0aW9uIGZyb20gdXNlcidzIGFjY291bnRpbmc/IA0KQW5kLCBmcm9tIGRyYWZ0LWhha2Fs YS1kaWFtZXRlci1jcmVkaXQtY29udHJvbC0wMS50eHQsIGl0IHNheXMgdGhhdCAiQ3JlZGl0IGNv bnRyb2wgaXMgYSBwcm9jZXNzIG9mIGNoZWNraW5nIGlmIGNyZWRpdCBpcyBhdmFpbGFibGUsIGNy ZWRpdC1yZXNlcnZhdGlvbiwgcmVkdWN0aW9uIG9mIGNyZWRpdCBmcm9tIHRoZSBlbmQgdXNlciBh Y2NvdW50IHdoZW4gc2VydmljZSBpcyBjb21wbGV0ZWQgYW5kIHJlZnVuZGluZyBvZiAgIHJlc2Vy dmVkIGNyZWRpdCBub3QgdXNlZC4iICBJcyBjcmVkaXQgdGhlIHNhbWUgbWVhbmluZyB3aXRoIG1v bmV5IG9yIHNvbWV0aW5nIHRvIHJlY29yZCBleHBlbnNlPw0KVGhhbmsgeW91Lg0K --=====002_Dragon427667882024_===== Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPFA+RnJvbSBSRkMgMjk3 NSAoMS4zIEFjY291bnRpbmcgbWFuYWdlbWVudCBhcmNoaXRlY3R1cmUpLCBiaWxsaW5nIHNlcnZl ciAiPFNQQU4gDQpzdHlsZT0ibXNvLWhhbnNpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tYmlkaS1m b250LWZhbWlseTogy87M5SI+PFNQQU4+Jm5ic3A7aGFuZGxlcyANCnJhdGluZyBhbmQgaW52b2lj ZSBnZW5lcmF0aW9uLCBidXQgbWF5IGFsc288L1NQQU4+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMg DQpzdHlsZT0ibXNvLWhhbnNpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tYmlkaS1mb250LWZhbWls eTogy87M5SI+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiA8L1NQQU4+Y2Fycnkg b3V0IGF1ZGl0aW5nLCBjb3N0IGFsbG9jYXRpb24sIHRyZW5kIA0KYW5hbHlzaXMgb3IgY2FwYWNp dHk8P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvU1BBTj48U1BBTj48U1BBTiANCnN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvU1BBTj5wbGFubmluZyBmdW5j dGlvbnMuIDwvU1BBTj4iIEkgYW0gDQpjb25mdXNlZCBieSB0aGlzIHNlbnRlbnNlLCBpcyBiaWxs aW5nIHNlcnZlciByZXNwb25zaWJsZSBmb3IgbW9uZXkgZGVkdWN0aW9uIA0KZnJvbSB1c2VyJ3Mg YWNjb3VudGluZz8gPC9QPg0KPFA+QW5kLCBmcm9tIDxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0i Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwLjVwdDsgbXNvLWJp ZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28t Zm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+ZHJhZnQtaGFrYWxh LWRpYW1ldGVyLWNyZWRpdC1jb250cm9sLTAxLnR4dCwgDQppdCBzYXlzIHRoYXQgIjxTUEFOIGxh bmc9RU4tVVM+Q3JlZGl0IGNvbnRyb2wgaXMgYSBwcm9jZXNzIG9mIGNoZWNraW5nIA0KaWY8L1NQ QU4+PFNQQU4gbGFuZz1FTi1VUz48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiA8L1NQ QU4+Y3JlZGl0IGlzIA0KYXZhaWxhYmxlLCBjcmVkaXQtcmVzZXJ2YXRpb24sIHJlZHVjdGlvbiBv ZiBjcmVkaXQgZnJvbTwvU1BBTj48U1BBTj48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+IDwvU1BBTj50aGUgZW5kIHVzZXIgYWNjb3VudCB3aGVuIHNlcnZpY2UgaXMgY29tcGxldGVk IA0KYW5kIHJlZnVuZGluZyBvZjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQt RkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMC41cHQ7IG1zby1iaWRpLWZv bnQtc2l6ZTogMTIuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQt a2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxTUEFOIA0Kc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFOPnJlc2VydmVkIGNyZWRpdCBub3Qg dXNlZC4iJm5ic3A7IA0KSXMgY3JlZGl0IHRoZSBzYW1lIG1lYW5pbmcgd2l0aCBtb25leSBvciBz b21ldGluZyB0byANCnJlY29yZCZuYnNwO2V4cGVuc2U/PC9TUEFOPjwvU1BBTj48L1A+DQo8UD48 U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsg Rk9OVC1TSVpFOiAxMC41cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxh bmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5n dWFnZTogQVItU0EiPjxTUEFOIA0KbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTAuNXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEy LjBwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mb250LWtlcm5pbmc6IDEu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1D TjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGFuayANCnlvdS48L1NQQU4+PC9TUEFOPjwv UD4NCjxQPiZuYnNwOzwvUD48L0JPRFk+PC9IVE1MPg0K --=====002_Dragon427667882024_=====-- From owner-aaa-wg@merit.edu Thu Jun 27 05:31: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 FAA07379 for ; Thu, 27 Jun 2002 05:31:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00CD7912F1; Thu, 27 Jun 2002 05:31:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC344912F2; Thu, 27 Jun 2002 05:31: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 3FAF9912F1 for ; Thu, 27 Jun 2002 05:31:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A4D65DD9D; Thu, 27 Jun 2002 05:31:34 -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 3B5135DD8E for ; Thu, 27 Jun 2002 05:31:33 -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 g5R9XMW18762 for ; Thu, 27 Jun 2002 12:33:22 +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, 27 Jun 2002 12:31:31 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 12:31:31 +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]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 12:31:30 +0300 Message-ID: <07A6D72550C5E0459DE676439EE53846E32BC2@esebe012.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIdp3mmWvvhO+vFReir6yow7lmMTgAE7xHg From: To: X-OriginalArrivalTime: 27 Jun 2002 09:31:31.0735 (UTC) FILETIME=[6BF9C270:01C21DBD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA07379 Hi! The "experimental" command-codes should stay available longer. Unless we want to create interoperability problems. Not all equipment in the network is updated overnight after the suitable IETF standardized Diameter Applications become available to replace the vendor-specific apps. I'd also like to state for the record that VSCs are a much better, formal, and controlled way to avoid interoperability problems compared to "experimental" command-codes. I guess the decision is already made, but I still hope everybody who is honestly concerned about interoperability considers this. BR, Mikko > -----Original Message----- > From: ext Randy Bush [mailto:randy@psg.com] > Sent: 27 June, 2002 09:42 > To: Tony Johansson > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Vendor Command Code resolution > > > > Okay, so if the conclusion with IESG is that we cannot keep > the VSCs and > > should instead have an experimental command code space > ^ temmporary > that will go away in a year or so. it's just a kindness to > help release > 5 > > randy > From owner-aaa-wg@merit.edu Thu Jun 27 05:43: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 FAA07609 for ; Thu, 27 Jun 2002 05:43:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E7CD912F2; Thu, 27 Jun 2002 05:43:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13545912F3; Thu, 27 Jun 2002 05:43: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 262A3912F2 for ; Thu, 27 Jun 2002 05:43:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 147BF5DEA4; Thu, 27 Jun 2002 05:43:51 -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 9DB955DD8E for ; Thu, 27 Jun 2002 05:43:50 -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 g5R9hnrU012616; Thu, 27 Jun 2002 11:43:49 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKQWX9P; Thu, 27 Jun 2002 11:43:49 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 11:43:48 +0200 Message-ID: <577066326047D41180AC00508B955DDA05ED247E@eestqnt104> X-Sybari-Trust: f9523720 7216406a 0b6f7280 00000138 From: "Miguel-Angel Pallares-Lopez (ECE)" To: "'mikko.aittola@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 11:43:41 +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, I must agree with both points expressed by Mikko. If we introduce experimental command codes as a replacement of VSCs, we must do it as a feature of the protocol that will be stable over time as any other feature. Even when an IETF standardized application become available to replace a vendor-specific one, there will be nodes that are not upgraded. I share Mikko's concern about interoperability. I still don't understand what interoperability problems the VSCs create and what are these experimental codes adding to solve them. The inclusion of a higher granularity in the meaning of an Application-Id seems a good idea. This, together with the clarification suggested by John: " DIAMETER_COMMAND_UNSUPPORTED 3001 The Request contained a Command-Code that the receiver did not recognize or support. This MUST be used when when a Diameter node receives an experimental command that it does not understand. " but talking about VSCs seems more than enough. BR/Miguel -----Original Message----- From: mikko.aittola@nokia.com [mailto:mikko.aittola@nokia.com] Sent: jueves, 27 de junio de 2002 11:32 To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Vendor Command Code resolution Hi! The "experimental" command-codes should stay available longer. Unless we want to create interoperability problems. Not all equipment in the network is updated overnight after the suitable IETF standardized Diameter Applications become available to replace the vendor-specific apps. I'd also like to state for the record that VSCs are a much better, formal, and controlled way to avoid interoperability problems compared to "experimental" command-codes. I guess the decision is already made, but I still hope everybody who is honestly concerned about interoperability considers this. BR, Mikko > -----Original Message----- > From: ext Randy Bush [mailto:randy@psg.com] > Sent: 27 June, 2002 09:42 > To: Tony Johansson > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Vendor Command Code resolution > > > > Okay, so if the conclusion with IESG is that we cannot keep > the VSCs and > > should instead have an experimental command code space > ^ temmporary > that will go away in a year or so. it's just a kindness to > help release > 5 > > randy > From owner-aaa-wg@merit.edu Thu Jun 27 07:42: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 HAA12172 for ; Thu, 27 Jun 2002 07:42:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00BB1912F9; Thu, 27 Jun 2002 07:42:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C032C912FA; Thu, 27 Jun 2002 07:42: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 C0A2C912F9 for ; Thu, 27 Jun 2002 07:42:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE4535DEAE; Thu, 27 Jun 2002 07:42:27 -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 150CE5DE1F for ; Thu, 27 Jun 2002 07:42:27 -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 g5RBgPrU020705; Thu, 27 Jun 2002 13:42:25 +0200 (MEST) Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHKQYLLD; Thu, 27 Jun 2002 13:42:26 +0200 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 13:42:25 +0200 Message-ID: <577066326047D41180AC00508B955DDA06C453AF@eestqnt104> X-Sybari-Trust: c55e1d26 7216406a 0b6f7280 00000138 From: "Carolina Canales Valenzuela (ECE)" To: "Miguel-Angel Pallares-Lopez (ECE)" , aaa-wg@merit.edu Cc: "'mikko.aittola@nokia.com'" Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 13:42:23 +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, one suggestion in order to solve this problem: Would it be OK for the IESG to forbid VSCs in *standard* applications, but allow them in Vendor-specific applications? My understanding of the interoperability problem is that it arises mainly when an VSC is used inside a *standard* application. The peer has announced the support of the standard application, but of course it could happen that it doesn't understand the VSC. I think that this is the most problematic issue. The solution might be to forbid the use of VSCs in standard applications, and use the experimental command codes for such purposes. If, even though, the peer does not support such experimental command, then it would answer back with an error, and the Result Code DIAMETER_COMMAND_UNSUPPORTED. However, for Vendor Specific Applications, once that the vendor has obtained the Vendor-Id from IANA, it could be the own vendor the one in charged of assigning the command codes inside the Vendor-Specific-App (i.e., leave the base as it used to be regarding this). There are no interoperability problems in this case, because such codes will be just sent to the peers that through CER/CEA advertised the support of the Vendor-Specific-App, and such command codes will always be marked with the Vendor-Specific-Application-Id (Vendor-Id + Vendor-App-Id), plus the Vendor-Id in the header, in case it is maintained. Like this, the feature would be stable over time, specially for the legacy R5 nodes. Comments? Carolina >-----Original Message----- >From: Miguel-Angel Pallares-Lopez (ECE) >[mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] >Sent: Thursday, June 27, 2002 11:44 AM >To: 'mikko.aittola@nokia.com'; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Vendor Command Code resolution > > >Hi, > >I must agree with both points expressed by Mikko. > >If we introduce experimental command codes as a replacement of >VSCs, we must do it as a feature of the protocol that will be >stable over time as any other feature. Even when an IETF >standardized application become available to replace a >vendor-specific one, there will be nodes that are not upgraded. > >I share Mikko's concern about interoperability. I still don't >understand what interoperability problems the VSCs create and >what are these experimental codes adding to solve them. The >inclusion of a higher granularity in the meaning of an >Application-Id seems a good idea. This, together with the >clarification suggested by John: > >" > DIAMETER_COMMAND_UNSUPPORTED 3001 > > The Request contained a Command-Code that the receiver did >not recognize or support. > This MUST be used when when a Diameter node receives an >experimental command that it > does not understand. > >" > >but talking about VSCs seems more than enough. > >BR/Miguel > >-----Original Message----- >From: mikko.aittola@nokia.com [mailto:mikko.aittola@nokia.com] >Sent: jueves, 27 de junio de 2002 11:32 >To: aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Vendor Command Code resolution > > >Hi! > >The "experimental" command-codes should stay available longer. >Unless we want to create interoperability problems. Not all >equipment in the network is updated overnight after the >suitable IETF standardized Diameter Applications become available >to replace the vendor-specific apps. > >I'd also like to state for the record that VSCs are a much better, >formal, and controlled way to avoid interoperability problems >compared to "experimental" command-codes. I guess the decision is >already made, but I still hope everybody who is honestly concerned >about interoperability considers this. > > >BR, >Mikko > > >> -----Original Message----- >> From: ext Randy Bush [mailto:randy@psg.com] >> Sent: 27 June, 2002 09:42 >> To: Tony Johansson >> Cc: aaa-wg@merit.edu >> Subject: Re: [AAA-WG]: Vendor Command Code resolution >> >> >> > Okay, so if the conclusion with IESG is that we cannot keep >> the VSCs and >> > should instead have an experimental command code space >> ^ temmporary >> that will go away in a year or so. it's just a kindness to >> help release >> 5 >> >> randy >> > From owner-aaa-wg@merit.edu Thu Jun 27 07:51: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 HAA12615 for ; Thu, 27 Jun 2002 07:51:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 06F37912FA; Thu, 27 Jun 2002 07:52:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0392912FB; Thu, 27 Jun 2002 07:52: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 C07E0912FA for ; Thu, 27 Jun 2002 07:52:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA4125DE1F; Thu, 27 Jun 2002 07:52:18 -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 08F225DDE0 for ; Thu, 27 Jun 2002 07:52:18 -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 g5RBs7W23827 for ; Thu, 27 Jun 2002 14:54:07 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 14:52:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 14:52: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: RE: [AAA-WG]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 14:52:01 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E82@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIdz8i17mlJuBc3QiiKFwczdO6+PgAABNkQ From: To: , , Cc: X-OriginalArrivalTime: 27 Jun 2002 11:52:02.0365 (UTC) FILETIME=[0D05CED0:01C21DD1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA12615 Hi all, > one suggestion in order to solve this problem: Would it be OK > for the IESG to forbid VSCs in *standard* applications, but > allow them in Vendor-specific applications? The IESG has been asking for the removal of VSCs since spring of 2001. I would not bet on this at all. Actually, I think that they say this would be a bigger problem. I've been told that inclusion of VSCs is a showstopper for the IESG. John From owner-aaa-wg@merit.edu Thu Jun 27 08:31: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 IAA14464 for ; Thu, 27 Jun 2002 08:31:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF9E0912FC; Thu, 27 Jun 2002 08:31:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84D1E912FE; Thu, 27 Jun 2002 08:31: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 67236912FC for ; Thu, 27 Jun 2002 08:31:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48D4E5DEB0; Thu, 27 Jun 2002 08:31:52 -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 F35C95DDE0 for ; Thu, 27 Jun 2002 08:31:51 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 05:31:51 -0700 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com '" , "'aboba@internaut.com '" , "'fredrik.johansson@ipunplugged.com '" Cc: "'gwz@cisco.com '" , "'aaa-wg@merit.edu '" Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 05:31:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21DD6.9AEF3510" 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_01C21DD6.9AEF3510 Content-Type: text/plain; charset="iso-8859-1" > New Diameter applications MUST define one Command Code or set of mandatory AVPs. > The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see section 3.2). > A new application MAY also define new AVPs. If the Diameter application has any > accounting requirements, it MUST also specify the AVPs that are to be present in > the Diameter Accounting messages (see section 9.3). Strange... we seem to go back to what the protocol had prior to the interim meeting at Nortel's facility a couple of years ago. At that time, the IESG, and others, voiced concern about having too many applications to standardize, where each app would include a single AVP defined by a vendor for a specific application. THen end result is like a menu where one has to find the right "set" of applications in order to get the peer to communicate. For that matter, it was decided that an app required a command code. PatC ------_=_NextPart_001_01C21DD6.9AEF3510 Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: Vendor Command Code resolution

> New Diameter applications MUST define one Command Code or set of mandatory AVPs.
> The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see section 3.2).
> A new application MAY also define new AVPs. If the Diameter application has any
> accounting requirements, it MUST also specify the AVPs that are to be present in
> the Diameter Accounting messages (see section 9.3).

Strange... we seem to go back to what the protocol had prior to the interim meeting
at Nortel's facility a couple of years ago. At that time, the IESG, and others,
voiced concern about having too many applications to standardize, where each app
would include a single AVP defined by a vendor for a specific application. THen end
result is like a menu where one has to find the right "set" of applications in order
to get the peer to communicate.

For that matter, it was decided that an app required a command code.

PatC

------_=_NextPart_001_01C21DD6.9AEF3510-- From owner-aaa-wg@merit.edu Thu Jun 27 08:46: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 IAA15098 for ; Thu, 27 Jun 2002 08:46:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 055C9912FE; Thu, 27 Jun 2002 08:46:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C800A91300; Thu, 27 Jun 2002 08:46:26 -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 7CCF8912FE for ; Thu, 27 Jun 2002 08:46:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 508485DEB3; Thu, 27 Jun 2002 08:46:18 -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 027235DEB1 for ; Thu, 27 Jun 2002 08:46:18 -0400 (EDT) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 05:46:17 -0700 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com '" , "'aaa-wg@merit.edu '" Subject: RE: [AAA-WG]: Vendor ID Date: Thu, 27 Jun 2002 05:46:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21DD8.A01E0AA0" 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_01C21DD8.A01E0AA0 Content-Type: text/plain; charset="iso-8859-1" Wasn't the whole goal of having vendor specific commands to eliminate the possibility of address space abuse as other vendors have done with RADIUS in the past? Are we really willing to take the risk of this happening all over again, and having systems abusing the same values, and therefore breaking interoperability? PatC -----Original Message----- From: john.loughney@nokia.com To: aaa-wg@merit.edu Sent: 6/26/2002 11:50 PM Subject: [AAA-WG]: Vendor ID In section 3 Diameter Header There is the Vendor-ID field: 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" [ASSIGNNO] 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 vendor's vendor-specific command, nor with future IETF applications. All vendor-specific Diameter commands require Informational RFCs documenting the command unless for Private Use as described in Section 11.2.1. My feeling is that should be updated to this: In the event that the Command-Code field contains an experimental command, the four-octet Vendor-ID field contains the IANA assigned "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value. If the Command-Code field contains an IETF standard Command, the Vendor-ID field MUST be set to zero (0). Any vendor using an experimental Diameter command MUST use their own Vendor-ID. John ------_=_NextPart_001_01C21DD8.A01E0AA0 Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: Vendor ID

Wasn't the whole goal of having vendor specific commands to eliminate the possibility
of address space abuse as other vendors have done with RADIUS in the past? Are we really
willing to take the risk of this happening all over again, and having systems abusing the
same values, and therefore breaking interoperability?

PatC

-----Original Message-----
From: john.loughney@nokia.com
To: aaa-wg@merit.edu
Sent: 6/26/2002 11:50 PM
Subject: [AAA-WG]: Vendor ID

In section 3 Diameter Header

There is the Vendor-ID field:

  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" [ASSIGNNO] 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 vendor's vendor-specific command, nor
with
  future IETF applications. All vendor-specific Diameter commands
require
  Informational RFCs documenting the command unless for Private Use as
described
  in Section 11.2.1.

My feeling is that should be updated to this:

  In the event that the Command-Code field contains an experimental
  command, the four-octet Vendor-ID field contains the IANA assigned
  "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value.
  If the Command-Code field contains an IETF standard Command, the
Vendor-ID
  field MUST be set to zero (0). Any vendor using an experimental
Diameter
  command MUST use their own Vendor-ID.

John

------_=_NextPart_001_01C21DD8.A01E0AA0-- From owner-aaa-wg@merit.edu Thu Jun 27 08:51: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 IAA15342 for ; Thu, 27 Jun 2002 08:51:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97D2E91300; Thu, 27 Jun 2002 08:51:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62E1091303; Thu, 27 Jun 2002 08:51:41 -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 3D07C91300 for ; Thu, 27 Jun 2002 08:51:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25D675DEB1; Thu, 27 Jun 2002 08:51:40 -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 4F9245DE99 for ; Thu, 27 Jun 2002 08:51:39 -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 g5RCoDd21499 for ; Thu, 27 Jun 2002 15:50:13 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Jun 2002 15:51:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 27 Jun 2002 15:51:38 +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]: Vendor ID Date: Thu, 27 Jun 2002 15:51:37 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65581@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor ID Thread-Index: AcId2KTDopbqiSRJTPmEQunstFuWFgAAIP9w From: To: , X-OriginalArrivalTime: 27 Jun 2002 12:51:38.0337 (UTC) FILETIME=[6077D510:01C21DD9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA15342 Hi Pat, > Wasn't the whole goal of having vendor specific commands to eliminate the possibility > of address space abuse as other vendors have done with RADIUS in the past? Are we really > willing to take the risk of this happening all over again, and having systems abusing the > same values, and therefore breaking interoperability? I thought so, but I'm just the messenger / editor. This has been raised by Randy Bush, in issue 268. John 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. From owner-aaa-wg@merit.edu Thu Jun 27 09:00: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 JAA15760 for ; Thu, 27 Jun 2002 09:00:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD5E491303; Thu, 27 Jun 2002 09:00:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 441E891304; Thu, 27 Jun 2002 09:00: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 312AB91303 for ; Thu, 27 Jun 2002 09:00:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B87F5DEB1; Thu, 27 Jun 2002 09:00:14 -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 8C69D5DE99 for ; Thu, 27 Jun 2002 09:00:11 -0400 (EDT) Received: (qmail 3804 invoked by uid 500); 27 Jun 2002 13:00:11 -0000 Date: Thu, 27 Jun 2002 08:00:10 -0500 From: David Frascone To: diameter@diameter.org, aaa-wg@merit.edu Subject: [AAA-WG]: www.diameter.org finally back up Message-ID: <20020627130010.GA3440@newman.frascone.com> Mail-Followup-To: diameter@diameter.org, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks to Kevin Purser, http://www.diameter.org has finally been ressurrected. Please let me (or him) know if there is other relevant material that should be added to the page. -Dave P.S. Sorry for the crosspost, but it seemed appropriate. -- David Frascone I do this kind of stuff to him all through the picture. From owner-aaa-wg@merit.edu Thu Jun 27 09:55: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 JAA18614 for ; Thu, 27 Jun 2002 09:55:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F065091305; Thu, 27 Jun 2002 09:56:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B565291306; Thu, 27 Jun 2002 09:56: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 A5D9C91305 for ; Thu, 27 Jun 2002 09:56:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87FBA5DE99; Thu, 27 Jun 2002 09:56:14 -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 DC32F5DD8C for ; Thu, 27 Jun 2002 09:56:13 -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 g5RDucUg012028; Thu, 27 Jun 2002 15:56:38 +0200 From: "Fredrik Johansson" To: "Carolina Canales Valenzuela (ECE)" , "Miguel-Angel Pallares-Lopez (ECE)" , Cc: Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Thu, 27 Jun 2002 15:56:50 +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) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <577066326047D41180AC00508B955DDA06C453AF@eestqnt104> 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 > Carolina Canales Valenzuela (ECE) > Sent: den 27 juni 2002 13:42 > To: Miguel-Angel Pallares-Lopez (ECE); aaa-wg@merit.edu > Cc: 'mikko.aittola@nokia.com' > Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > Hi, > one suggestion in order to solve this problem: Would it be OK for > the IESG to forbid VSCs in *standard* applications, but allow > them in Vendor-specific applications? > > My understanding of the interoperability problem is that it > arises mainly when an VSC is used inside a *standard* > application. That's why Glen suggested that a VSC required a new application-id. i.e. you can't send a VSC in a standard application, the only thing you can do is to send vendor specific avps. /fredrik The peer has announced the support of the standard > application, but of course it could happen that it doesn't > understand the VSC. I think that this is the most problematic > issue. The solution might be to forbid the use of VSCs in > standard applications, and use the experimental command codes for > such purposes. If, even though, the peer does not support such > experimental command, then it would answer back with an error, > and the Result Code DIAMETER_COMMAND_UNSUPPORTED. > > However, for Vendor Specific Applications, once that the vendor > has obtained the Vendor-Id from IANA, it could be the own vendor > the one in charged of assigning the command codes inside the > Vendor-Specific-App (i.e., leave the base as it used to be > regarding this). There are no interoperability problems in this > case, because such codes will be just sent to the peers that > through CER/CEA advertised the support of the > Vendor-Specific-App, and such command codes will always be marked > with the Vendor-Specific-Application-Id (Vendor-Id + > Vendor-App-Id), plus the Vendor-Id in the header, in case it is > maintained. > Like this, the feature would be stable over time, specially for > the legacy R5 nodes. I agree, I would much more prefer to keep the vendor specific than having some experimental stuff. the vendor specific has been thought thru and it works. Why change to something new that has not been carefully reviewed? /fredrik > > Comments? > > Carolina > > >-----Original Message----- > >From: Miguel-Angel Pallares-Lopez (ECE) > >[mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > >Sent: Thursday, June 27, 2002 11:44 AM > >To: 'mikko.aittola@nokia.com'; aaa-wg@merit.edu > >Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > > > >Hi, > > > >I must agree with both points expressed by Mikko. > > > >If we introduce experimental command codes as a replacement of > >VSCs, we must do it as a feature of the protocol that will be > >stable over time as any other feature. Even when an IETF > >standardized application become available to replace a > >vendor-specific one, there will be nodes that are not upgraded. > > > >I share Mikko's concern about interoperability. I still don't > >understand what interoperability problems the VSCs create and > >what are these experimental codes adding to solve them. The > >inclusion of a higher granularity in the meaning of an > >Application-Id seems a good idea. This, together with the > >clarification suggested by John: > > > >" > > DIAMETER_COMMAND_UNSUPPORTED 3001 > > > > The Request contained a Command-Code that the receiver did > >not recognize or support. > > This MUST be used when when a Diameter node receives an > >experimental command that it > > does not understand. > > > >" > > > >but talking about VSCs seems more than enough. > > > >BR/Miguel > > > >-----Original Message----- > >From: mikko.aittola@nokia.com [mailto:mikko.aittola@nokia.com] > >Sent: jueves, 27 de junio de 2002 11:32 > >To: aaa-wg@merit.edu > >Subject: RE: [AAA-WG]: Vendor Command Code resolution > > > > > >Hi! > > > >The "experimental" command-codes should stay available longer. > >Unless we want to create interoperability problems. Not all > >equipment in the network is updated overnight after the > >suitable IETF standardized Diameter Applications become available > >to replace the vendor-specific apps. > > > >I'd also like to state for the record that VSCs are a much better, > >formal, and controlled way to avoid interoperability problems > >compared to "experimental" command-codes. I guess the decision is > >already made, but I still hope everybody who is honestly concerned > >about interoperability considers this. > > > > > >BR, > >Mikko > > > > > >> -----Original Message----- > >> From: ext Randy Bush [mailto:randy@psg.com] > >> Sent: 27 June, 2002 09:42 > >> To: Tony Johansson > >> Cc: aaa-wg@merit.edu > >> Subject: Re: [AAA-WG]: Vendor Command Code resolution > >> > >> > >> > Okay, so if the conclusion with IESG is that we cannot keep > >> the VSCs and > >> > should instead have an experimental command code space > >> ^ temmporary > >> that will go away in a year or so. it's just a kindness to > >> help release > >> 5 > >> > >> randy > >> > > From owner-aaa-wg@merit.edu Thu Jun 27 11:04: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 LAA22339 for ; Thu, 27 Jun 2002 11:04:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5342391308; Thu, 27 Jun 2002 11:02:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CD1F91309; Thu, 27 Jun 2002 11:02: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 B341291308 for ; Thu, 27 Jun 2002 11:02:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93C045DEB6; Thu, 27 Jun 2002 11:02:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 43B2C5DD8C for ; Thu, 27 Jun 2002 11:02:38 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5RF2Xq17012; Thu, 27 Jun 2002 11:02:33 -0400 (EDT) Received: from mccap-1.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA19800; Thu, 27 Jun 2002 10:02:32 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id GYDDS6-00011K-00; Thu, 27 Jun 2002 11:02:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15643.10500.373539.281694@gargle.gargle.HOWL> Date: Thu, 27 Jun 2002 10:02:28 -0500 From: Pete McCann To: Cc: , , Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65570@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65570@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 Hi, john.loughney@nokia.com writes: > > > Since, this will be just a pool of experimental command codes, which means that > > > the same experimental command code may be reused in several vendor specific > > > application, we need application IDs and the Vendor ID in the Diameter header > > > (as of today, i.e. let be as is) to guarantee avoiding conflict. > > > > Yes. > > Actually, if the experimental command code contains an application > id, isn't that enough? > It might not be elegant, but it works. Do you mean that the command would contain a Vendor-Specific Application ID AVP? I don't think you want to try encoding the application ID within the command code, especially if we want to limit the number of bits in the experimental space. Also, I am having trouble reconciling this statement with your suggested text: > In the event that the Command-Code field contains an experimental > command, the four-octet Vendor-ID field contains the IANA assigned > "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value. > If the Command-Code field contains an IETF standard Command, the Vendor-ID > field MUST be set to zero (0). Any vendor using an experimental Diameter > command MUST use their own Vendor-ID. This text seems to keep VSCs; the experimental space would differ from VSCs in name only, or would only serve to limit the number of VSCs that could be allocated by a single vendor by restricting VSCs to a particular range of command codes. Will that really satisfy the IESG's concerns? As an alternative, in line with what you might have been suggesting earlier, why don't we just remove the Vendor-ID from the Diameter header, and require any experimental command to include a vendor-specific application ID AVP. That way, to demultiplex the command, you would need to look for the AVP, but processing for the standard commands would be streamlined. This would allow vendors to create as many experimental applications as they have Application IDs, and the experimental command code space could be re-used across different (vendor, application) pairs. This approach would be pretty non-optimal in terms of processing required for vendor specific commands, but might be much more likely to answer Randy's concerns. Here is some proposed text for Section 3: 3 Diameter Header A summary of the Diameter header format is shown below. The fields are transmitted in network byte order. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Version This Version field MUST be set to 1 to indicate Diameter Version 1. Message Length ... Command-Code 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). Command-Code values in the range 0xffff00 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. Hop-by-Hop Identifier ... Also, change 6.11 to say: 6.11 Vendor-Specific-Application-Id AVP The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type Grouped and is used to advertise support of a vendor-specific Diameter Application. Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present. This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application. AVP Format ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } So this approach reserves 256 experimental codes, which should be more than enough for any application. They can be re-used across different vendors and across different applications within a vendor, if necessary. They are off the fast-path for standard command processing. If the IESG wants to remove/deprecate the use of the space later they can do so without changes to the base protocol, although I am not sure about how this would affect the deployed base. -Pete From owner-aaa-wg@merit.edu Thu Jun 27 17:52: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 RAA18538 for ; Thu, 27 Jun 2002 17:52:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79D9191239; Thu, 27 Jun 2002 17:53:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BB289123B; Thu, 27 Jun 2002 17:53:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49AAB91239 for ; Thu, 27 Jun 2002 17:53:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F4315DEAB; Thu, 27 Jun 2002 17:53:12 -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 ACBFD5DD9B for ; Thu, 27 Jun 2002 17:53:11 -0400 (EDT) Received: from GWZW2K (sjc-vpn3-361.cisco.com [10.21.65.105]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA03473; Thu, 27 Jun 2002 14:53:03 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Randy Bush" , "Bernard Aboba" Cc: Subject: RE: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts Date: Thu, 27 Jun 2002 14:52:54 -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 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Some time ago, Randy Bush [mailto://randy@psg.com] wrote: > > The AAA WG has completed WG last call on the Diameter Base-10 and > > Transport-07 documents. As a result of WG last call comments, no > > changes were made to the Transport document, and 20 changes were > > made to the Diameter Base document, with 5 comments rejected. > > as ad, i will not be passing this to the iesg for review. there > is one comment that has not been addressed by -11, vendor-specific > commands. as i have repeatedly said, if i was to pass this to the > iesg, it is a sure show-stopper. > > rather than saying it all over again, can folk please review the > mailing list archive on this. The archives are available again, so I attempted to review them. However, it appears that the archives are incomplete: I couldn't find a single message in them on this topic from any IESG member. > essentially, the iesg has a hot- > button about mandatory vendor commands. Given the above, I (and perhaps the rest of the WG) would _really_ appreciate it if you (or anyone else on the IESG) would take the time to explain 1) where in the current document mandatory vendor commands are specified and 2) how the mechanisms in the current protocol are dangerous to interoperability. It would be _extra_ wonderful if this explanation had some technical qualities (as opposed to hot flashes) and evinced that the explainer had actually read the document in question. > > randy > > > From owner-aaa-wg@merit.edu Fri Jun 28 06: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 GAA16650 for ; Fri, 28 Jun 2002 06:18:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F10E791332; Fri, 28 Jun 2002 06:18:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 469B291333; Fri, 28 Jun 2002 06:18: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 AEF2791332 for ; Fri, 28 Jun 2002 06:17:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 917DF5DE0D; Fri, 28 Jun 2002 06:17:10 -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 B87A05DD92 for ; Fri, 28 Jun 2002 06:17:09 -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 g5SAHai07629 for ; Fri, 28 Jun 2002 13:17:36 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 13:17:07 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 13:17: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-8859-1" Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Fri, 28 Jun 2002 13:17:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65596@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcId66x6P1mVB6rNTM+dUiMEJGTi3gAoTISQ From: To: Cc: , , X-OriginalArrivalTime: 28 Jun 2002 10:17:05.0419 (UTC) FILETIME=[F3CA95B0:01C21E8C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16650 Hi Pete, > As an alternative, in line with what you might have been suggesting > earlier, why don't we just remove the Vendor-ID from the Diameter > header, and require any experimental command to include a > vendor-specific application ID AVP. That way, to demultiplex the > command, you would need to look for the AVP, but processing for the > standard commands would be streamlined. This would allow vendors to > create as many experimental applications as they have Application IDs, > and the experimental command code space could be re-used across > different (vendor, application) pairs. This approach would be pretty > non-optimal in terms of processing required for vendor specific > commands, but might be much more likely to answer Randy's concerns. Actually, this is what I was getting at, I think your text is good, so I will make the updated changes. Thanks, John > Here is some proposed text for Section 3: > > > > 3 Diameter Header > > A summary of the Diameter header format is shown below. The fields > are transmitted in network byte order. > > 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 > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > Version > This Version field MUST be set to 1 to indicate Diameter Version > 1. > > Message Length > ... > > Command-Code > 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). > > Command-Code values in the range 0xffff00 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. > > Hop-by-Hop Identifier > ... > > > Also, change 6.11 to say: > > > 6.11 Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present. > > This AVP MUST also be present as the first AVP in all > experimental commands defined in the vendor-specific application. > > AVP Format > > ::= < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > > > > So this approach reserves 256 experimental codes, which should be more > than enough for any application. They can be re-used across different > vendors and across different applications within a vendor, if > necessary. They are off the fast-path for standard command > processing. If the IESG wants to remove/deprecate the use of the > space later they can do so without changes to the base protocol, > although I am not sure about how this would affect the deployed base. > > -Pete > > From owner-aaa-wg@merit.edu Fri Jun 28 06:27: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 GAA16876 for ; Fri, 28 Jun 2002 06:27:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF06391333; Fri, 28 Jun 2002 06:27:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A14191334; Fri, 28 Jun 2002 06:27: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 6064D91333 for ; Fri, 28 Jun 2002 06:27:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D0CF5DE0D; Fri, 28 Jun 2002 06:27:47 -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 C4F3B5DD92 for ; Fri, 28 Jun 2002 06:27:46 -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 g5SASEi15994 for ; Fri, 28 Jun 2002 13:28:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Jun 2002 13:27:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 13:27: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-8859-1" Subject: RE: [AAA-WG]: Vendor Command Code resolution Date: Fri, 28 Jun 2002 13:27:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E87@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcId66x6P1mVB6rNTM+dUiMEJGTi3gAoi7/w From: To: Cc: , , X-OriginalArrivalTime: 28 Jun 2002 10:27:45.0780 (UTC) FILETIME=[7179EB40:01C21E8E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16876 Hi Pete, One more small change that is needed to be made is that the following ABNF: 3.2 Command Code ABNF specification header = "<" Diameter-Header:" [vendor-id] command-id [r-bit] [p-bit] [e-bit] ">" vendor-id = 1*DIGIT ":" should become: header = "<" Diameter-Header:" command-id [r-bit] [p-bit] [e-bit] ">" and I think that should be enough. John From owner-aaa-wg@merit.edu Fri Jun 28 09:25: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 JAA25314 for ; Fri, 28 Jun 2002 09:25:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7689191336; Fri, 28 Jun 2002 09:25:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4197291337; Fri, 28 Jun 2002 09:25: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 58A1791336 for ; Fri, 28 Jun 2002 09:25:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37EC95DED9; Fri, 28 Jun 2002 09:25:53 -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 CB03C5DD9E for ; Fri, 28 Jun 2002 09:25:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5SCWqq17315; Fri, 28 Jun 2002 05:32:52 -0700 Date: Fri, 28 Jun 2002 05:32:52 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: mccap@lucent.com, , Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65596@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 > > different (vendor, application) pairs. This approach would be pretty > > non-optimal in terms of processing required for vendor specific > > commands, but might be much more likely to answer Randy's concerns. Question: do changes need to be made to routing in order for this to work? From owner-aaa-wg@merit.edu Fri Jun 28 09:40: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 JAA25959 for ; Fri, 28 Jun 2002 09:40:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E56809132F; Fri, 28 Jun 2002 09:41:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B47BA91337; Fri, 28 Jun 2002 09:41: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 A70369132F for ; Fri, 28 Jun 2002 09:41:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F1895DEA5; Fri, 28 Jun 2002 09:41:10 -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 E52A55DD9E for ; Fri, 28 Jun 2002 09:41:09 -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 g5SDfai14703 for ; Fri, 28 Jun 2002 16:41: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 ; Fri, 28 Jun 2002 16:41:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 28 Jun 2002 16:41:07 +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]: Vendor Command Code resolution Date: Fri, 28 Jun 2002 16:41:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E8B@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIep2FeArzRwPHXSN66qmxWB7RPdwAARsTg From: To: Cc: , , X-OriginalArrivalTime: 28 Jun 2002 13:41:07.0522 (UTC) FILETIME=[74A74220:01C21EA9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA25959 Hi Bernard, > > > different (vendor, application) pairs. This approach would be pretty > > > non-optimal in terms of processing required for vendor specific > > > commands, but might be much more likely to answer Randy's > concerns. > > Question: do changes need to be made to routing in order for this to > work? My assumption would be that this is fairly transparent, but I will check into this. John From owner-aaa-wg@merit.edu Fri Jun 28 18:48: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 SAA26697 for ; Fri, 28 Jun 2002 18:48:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ACA1E91340; Fri, 28 Jun 2002 18:48:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DD8491341; Fri, 28 Jun 2002 18:48: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 10C4991340 for ; Fri, 28 Jun 2002 18:47:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E36895DEC0; Fri, 28 Jun 2002 18:47:17 -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 B3A235DE15 for ; Fri, 28 Jun 2002 18:47:17 -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 g5SMixTF007349; Fri, 28 Jun 2002 18:44:59 -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 SAA09829; Fri, 28 Jun 2002 18:45:11 -0400 (EDT) Date: Fri, 28 Jun 2002 18:44:57 -0400 To: Pete McCann Cc: john.loughney@nokia.com, aboba@internaut.com, tony.johansson@ericsson.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Vendor Command Code resolution Message-ID: <20020628224457.GI918@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65570@esebe004.NOE.Nokia.com> <15643.10500.373539.281694@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <15643.10500.373539.281694@gargle.gargle.HOWL> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 149 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jun 27, 2002 at 10:02:28AM -0500, Pete McCann wrote: > > Hi, > > john.loughney@nokia.com writes: > > > > Since, this will be just a pool of experimental command codes, which means that > > > > the same experimental command code may be reused in several vendor specific > > > > application, we need application IDs and the Vendor ID in the Diameter header > > > > (as of today, i.e. let be as is) to guarantee avoiding conflict. > > > > > > Yes. > > > > Actually, if the experimental command code contains an application > > id, isn't that enough? > > It might not be elegant, but it works. I think the same experimental command code is difficult to be reused in several vendor specific application, if a single Diameter node is trying to support those application with different Vendor-IDs. This would affect the way of command dictionary lookup. How do you think what the dictionary lookup key should be for the suggested change? In the -11 draft, command dictionary is looked up by using Command-Code and Vendor-ID (both appear in the Diameter header) as the lookup key. If lookup key is going to include information contained in an AVP as well as Command-Code, that would complicate message parser implementation (no good at all, please don't do that!!). On the other hand, if lookup key uses only Command-Code, it would work only when different vendors use different code values in experimental command code space.... Yoshihiro Ohba > > Do you mean that the command would contain a Vendor-Specific > Application ID AVP? I don't think you want to try encoding the > application ID within the command code, especially if we want to limit > the number of bits in the experimental space. > > Also, I am having trouble reconciling this statement with your > suggested text: > > > In the event that the Command-Code field contains an experimental > > command, the four-octet Vendor-ID field contains the IANA assigned > > "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value. > > If the Command-Code field contains an IETF standard Command, the Vendor-ID > > field MUST be set to zero (0). Any vendor using an experimental Diameter > > command MUST use their own Vendor-ID. > > This text seems to keep VSCs; the experimental space would differ from > VSCs in name only, or would only serve to limit the number of VSCs > that could be allocated by a single vendor by restricting VSCs to a > particular range of command codes. Will that really satisfy the > IESG's concerns? > > > As an alternative, in line with what you might have been suggesting > earlier, why don't we just remove the Vendor-ID from the Diameter > header, and require any experimental command to include a > vendor-specific application ID AVP. That way, to demultiplex the > command, you would need to look for the AVP, but processing for the > standard commands would be streamlined. This would allow vendors to > create as many experimental applications as they have Application IDs, > and the experimental command code space could be re-used across > different (vendor, application) pairs. This approach would be pretty > non-optimal in terms of processing required for vendor specific > commands, but might be much more likely to answer Randy's concerns. > > Here is some proposed text for Section 3: > > > > 3 Diameter Header > > A summary of the Diameter header format is shown below. The fields > are transmitted in network byte order. > > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > Version > This Version field MUST be set to 1 to indicate Diameter Version > 1. > > Message Length > ... > > Command-Code > 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). > > Command-Code values in the range 0xffff00 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. > > Hop-by-Hop Identifier > ... > > > Also, change 6.11 to say: > > > 6.11 Vendor-Specific-Application-Id AVP > > The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type > Grouped and is used to advertise support of a vendor-specific > Diameter Application. Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present. > > This AVP MUST also be present as the first AVP in all > experimental commands defined in the vendor-specific application. > > AVP Format > > ::= < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > > > > So this approach reserves 256 experimental codes, which should be more > than enough for any application. They can be re-used across different > vendors and across different applications within a vendor, if > necessary. They are off the fast-path for standard command > processing. If the IESG wants to remove/deprecate the use of the > space later they can do so without changes to the base protocol, > although I am not sure about how this would affect the deployed base. > > -Pete > > From owner-aaa-wg@merit.edu Sat Jun 29 09:19: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 JAA24582 for ; Sat, 29 Jun 2002 09:18:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E32B9120E; Sat, 29 Jun 2002 09:18:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5512591351; Sat, 29 Jun 2002 09:18: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 03EF39120E for ; Sat, 29 Jun 2002 09:18:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4A425DE1F; Sat, 29 Jun 2002 09:18: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 511F25DDA6 for ; Sat, 29 Jun 2002 09:13:44 -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 g5TDE0i20200 for ; Sat, 29 Jun 2002 16:14:00 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 29 Jun 2002 16:13:31 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 29 Jun 2002 16:13:29 +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]: Vendor Command Code resolution Date: Sat, 29 Jun 2002 16:13:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655AF@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIep2FeArzRwPHXSN66qmxWB7RPdwAxy6gg From: To: Cc: , , X-OriginalArrivalTime: 29 Jun 2002 13:13:30.0201 (UTC) FILETIME=[C339E490:01C21F6E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA24582 Hi Bernard, > > > different (vendor, application) pairs. This approach > would be pretty > > > non-optimal in terms of processing required for vendor specific > > > commands, but might be much more likely to answer Randy's > concerns. > > Question: do changes need to be made to routing in order for this to > work? Looking over this, I don't think it would matter. Essentially, it would be the same as for any other application (NASREQ, MIP). The experimental code would be in a vendor-specific application, so it has no new needs for routing - just the same as any other application. John From owner-aaa-wg@merit.edu Sun Jun 30 07:50: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 HAA28693 for ; Sun, 30 Jun 2002 07:50:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D62591247; Sun, 30 Jun 2002 07:51:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D01691249; Sun, 30 Jun 2002 07:51: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 E6F5691247 for ; Sun, 30 Jun 2002 07:51:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D51E95DDEB; Sun, 30 Jun 2002 07:51:02 -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 0922F5DD96 for ; Sun, 30 Jun 2002 07:51:02 -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 g5UBqsW14575 for ; Sun, 30 Jun 2002 14:52:54 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 30 Jun 2002 14:51:00 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 30 Jun 2002 14:51:00 +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: Sun, 30 Jun 2002 14:51:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01130572@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIe9f+elaN56d7YQdi1Sy/FiqFuOABLQAKg From: To: , Cc: , , X-OriginalArrivalTime: 30 Jun 2002 11:51:00.0687 (UTC) FILETIME=[677FBDF0:01C2202C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yoshimiro, > How do you think what the dictionary lookup key should be for the > suggested change? In the -11 draft, command dictionary is looked up > by using Command-Code and Vendor-ID (both appear in the Diameter > header) as the lookup key. If lookup key is going to include > information contained in an AVP as well as Command-Code, that would > complicate message parser implementation (no good at all, please don't > do that!!). On the other hand, if lookup key uses only Command-Code, > it would work only when different vendors use different code values in > experimental command code space.... 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. Your observation is correct, but this is a feature that the IESG does not wish to see in Diameter. John From owner-aaa-wg@merit.edu Sun Jun 30 10:51: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 KAA02154 for ; Sun, 30 Jun 2002 10:51:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE31D91210; Sun, 30 Jun 2002 10:51:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9F839121A; Sun, 30 Jun 2002 10:51: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 A7E7C91210 for ; Sun, 30 Jun 2002 10:51:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 906F95DDEF; Sun, 30 Jun 2002 10:51:51 -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 315FF5DD96 for ; Sun, 30 Jun 2002 10:51:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g5UE0LU15796; Sun, 30 Jun 2002 07:00:21 -0700 Date: Sun, 30 Jun 2002 07:00:21 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: yohba@tari.toshiba.com, , , Subject: RE: [AAA-WG]: Vendor Command Code resolution In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01130572@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 > Your observation is correct, but this is a feature that the IESG > does not wish to see in Diameter. The comment still stands, though -- that it is very awkward to be unable to interpret the command without parsing AVPs. Perhaps the application ID should go in the header? From owner-aaa-wg@merit.edu Sun Jun 30 14:03:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07775 for ; Sun, 30 Jun 2002 14:03:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 104569124B; Sun, 30 Jun 2002 14:03:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C80009124C; Sun, 30 Jun 2002 14:03:35 -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 6BC9E9124B for ; Sun, 30 Jun 2002 14:03:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5926C5DDEF; Sun, 30 Jun 2002 14:03:32 -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 AE5085DE13 for ; Sun, 30 Jun 2002 14:03:31 -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 g5UI40i11710 for ; Sun, 30 Jun 2002 21:04:00 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 30 Jun 2002 21:03:30 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 30 Jun 2002 21:03: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]: Vendor Command Code resolution Date: Sun, 30 Jun 2002 21:03:29 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655B4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIgRai0eRbF9P9gSrmakAV/ddKtlgAGj6mQ From: To: Cc: , , , X-OriginalArrivalTime: 30 Jun 2002 18:03:30.0392 (UTC) FILETIME=[70F61580:01C22060] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA07775 Hi Bernard, > The comment still stands, though -- that it is very awkward to be unable > to interpret the command without parsing AVPs. Perhaps the application > ID should go in the header? I've been debating this myself. Currently, Application ID is in the ACR, ACA and the CER, CEA messages. We have 3 types of Application IDs: Authorization Accounting Vendor Specific If we allow 32 bits for the Application ID that should be enough, if we make a generic Application ID. I'm going to make a test edit of the doc and see if it makes sense to move this into the header. John From owner-aaa-wg@merit.edu Sun Jun 30 15:06:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09233 for ; Sun, 30 Jun 2002 15:06:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C61659124E; Sun, 30 Jun 2002 15:07:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F9BE9124F; Sun, 30 Jun 2002 15:07: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 32FDB9124E for ; Sun, 30 Jun 2002 15:07:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15C595DE1A; Sun, 30 Jun 2002 15:07:26 -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 4099F5DDA5 for ; Sun, 30 Jun 2002 15:07:25 -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 g5UJ5wd01118 for ; Sun, 30 Jun 2002 22:05:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 30 Jun 2002 22:07:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 30 Jun 2002 22:07: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-8859-1" Subject: [AAA-WG]: Applicaiton ID in the header Date: Sun, 30 Jun 2002 22:07:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E8C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIgRai0eRbF9P9gSrmakAV/ddKtlgAGj6mQAAIEkJA= From: To: X-OriginalArrivalTime: 30 Jun 2002 19:07:24.0142 (UTC) FILETIME=[5E0DE8E0:01C22069] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA09233 Hi all, Studying this a bit further, I propose the following: 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+- Where the application id can be one of the following: authentication application id accounting application id vendor specific application id IANA will assign a range of application ids: 0x0000001 - 0x00ffffff for standard applications 0xff00000 - 0xfffffffe for vendor specific applications Vendor-specific applicaion ids must be registered via IANA The application id in the header MUST be the same as what is contained in any relevant AVPs. I think this will make things much clearer. Comments? John From owner-aaa-wg@merit.edu Sun Jun 30 15: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 PAA09458 for ; Sun, 30 Jun 2002 15:18:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0068E9124F; Sun, 30 Jun 2002 15:19:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC15B91250; Sun, 30 Jun 2002 15:19: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 836C19124F for ; Sun, 30 Jun 2002 15:19:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 719685DE08; Sun, 30 Jun 2002 15:19:22 -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 CD6355DDA5 for ; Sun, 30 Jun 2002 15:19:21 -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 g5UJHtd03019 for ; Sun, 30 Jun 2002 22:17:55 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 30 Jun 2002 22:19:20 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 30 Jun 2002 22:15:20 +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]: Text needed for: Applicaiton ID in the header Date: Sun, 30 Jun 2002 22:15:44 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC655B6@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Vendor Command Code resolution Thread-Index: AcIgRai0eRbF9P9gSrmakAV/ddKtlgAGj6mQAAIEkJAAAIajYA== From: To: , X-OriginalArrivalTime: 30 Jun 2002 19:15:20.0023 (UTC) FILETIME=[79B39670:01C2206A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA09458 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.