From owner-aaa-wg@merit.edu Wed Sep 1 01:51:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09394 for ; Wed, 1 Sep 2004 01:51:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FF20912CC; Wed, 1 Sep 2004 01:50:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C51519126D; Wed, 1 Sep 2004 01:50: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 783B3912CC for ; Wed, 1 Sep 2004 01:50:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53411843F3; Wed, 1 Sep 2004 01:50:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 438DD843ED for ; Wed, 1 Sep 2004 01:50:44 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i815ogT24326 for ; Wed, 1 Sep 2004 08:50:42 +0300 (EET DST) X-Scanned: Wed, 1 Sep 2004 08:48:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i815maEV028183 for ; Wed, 1 Sep 2004 08:48:36 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00n4SCfI; Wed, 01 Sep 2004 08:48:25 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i815mJY11342 for ; Wed, 1 Sep 2004 08:48:19 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 1 Sep 2004 08:48:10 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 1 Sep 2004 08:48:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: IETF 60 meeting minutes Date: Wed, 1 Sep 2004 08:48:09 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D0891C2@esebe056.ntc.nokia.com> Thread-Topic: IETF 60 meeting minutes Thread-Index: AcSP50NEg7Ov/fdlSuaXt6lVlOcy9A== From: To: X-OriginalArrivalTime: 01 Sep 2004 05:48:09.0150 (UTC) FILETIME=[42A455E0:01C48FE7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable AAA WG meeting Tuesday, August 03, 2004, IETF-60, San Diego Minute taker: Lakshminath Dondeti, ldondeti@nortelnetworks.com +++++++++++ NASREQ: some comments off the mike Diameter: waiting for Allison M., comment Diameter EAP finished WG last call DIAMETER-SIP and aaa-uri in AAA WG last call First session presentations: Diameter EAP: Pasi E. first WGLC ended in Seoul meeting Clarifications Which application id to be used. Open: issues 465-7=20 Proposal to incorporate 465 and 466 , but not 467 Send to IESG %no discussion =20 +++++++++++++++++ EAP key management issues: Bernard, A. Review of the doc: =20 participants: EAP peer (multiple ports), Authenticator w/ multiple ports, and then the AS 0 Discovery 1 Authentication 1a EAP auth 1b AAA key xport 2 SA establishment 2a unicast 2b multicast Conversation:=20 Requirements: Outlined by Russ H at IETF-56 Algorithm independence, fresh and strong keys, replay detection, authenticate all parties. + perform client and NAS authorization + Maintain confidentiality of sess keys + confirm selection of best suite + address cascading vulnerability problem + bind key to ctxt *Some relate to AAA* EAP: media, method and ciphersuite independence Types of EAP keys: calculated locally, exported by EAP method, etc., EAP key hierarchy: changes: long term credential Key naming: MSK, EMSK, AMSK, AAA-Key Key lifetime issues: negotiation, out of band mgmt Lifetime mgmt: Transient EAP keys existing attr: session-timeout AAA-Key caching Glenn Z., force key lifetime to be of the same lifetime as the session can't have a key lifetime shorter than session lifetime Bernard: can conceivably do rekeying during a session do you rekey or reauth to renew? G Z: force rekey and reauth to be the same Pasi E: since EMSK is between client and AAA server; they talk EAP, = which does not separate reauth and rekey. B A: in WPA can rekey without reauth Jari A: that's a rekey at a lower layer B A: need to be clear about what is being rekeyed Pat C: PMK rekey vs. PTK rekey=20 B A: w.r.t exported keys there is no rekey without reauth (Transient keys can be rekeyed) G Z: in EAP that's true; from AAA pov it's not true. e.g., session timeout is forever; but we want to change key without reauth B A: this is not the same as fast resume J A: problem with AAA rekeying GZ proposes is that we need a new mechanism P E: EAP can't do that! J A: it's DIAMETER EAP; probably something that can be done in the future; not in any of the current WG docs ??: not good to cache EMSK J A: can you explain that? If you don't cache the EMSK, when can the app request an AMSK ??: app based J A: how would that work: chick and egg problem ??: discuss in=20 B A: EAP WG more on this at the EAP WG ... ++++++++++++++++++++++++++++++++++ Glenn Z: Alternative EAP keying approaches. 1. RADIUS-keywrap Govt requirements This makes it easy for companies to sell to govt bodies: Just use IPsec does not work: run RADIUS over IPsec; hardly anyone = supports it does not authenticate to a process which you are speaking vulnerable to Trojans (talking to right box, without the right server/process does not work) Is not possible for an app to know that IPsec is running; need verifiable security. App layer security is better. Pasi E: widely known that IPsec for app layer security does not work. G Z: IPsec might require a PKI for "proper" operation J A: keywrap is better. Works for DIA/RAD. key protected by TLS can be "keywrap"ped. P C: NIST approval is still harder. MD5 is still used G Z: no there is no MD5 2. RADIUS-keyreq EAP rekeying and authentication are the same operation. AAA client authenticating to server or vice versa, and needs a new key is the app being considered. J A: Q: Is this not going to be applied for RAD/DIA? G Z: can't think of why not? J A: we are not doing another keying model! ??:=20 Missed some discussion between Bernard and Glen John L: does not impact RAD/DIA. So, no updates needed there. ++++++++++++++++++++ 2nd session ++++++++++++++++++++ Diameter Mobile IPv4: 18 & 19 Addressing IESG comments ++++++++++++++ NASREQ-17: fixing last minute issues/bugs, and addressing IESG review doc going to the RFC editor Changes: issues: 464, 466, 468 ++++++++++++++ CC-05: Addressing Allison M.'s discuss: I: Too 3GPP specific=20 A: AVPs are extensible I: need to think broadly about SIP A: will add text I: Message flow diags too 3GPP specific A: will update to be more general IANA issues TB addressed Ted H Discuss: I 4.1 needs clean up: guidelines for interoperability A: proposed text ok'ed I: 5.5 I: credit fragmentation (has been cleared) > Allison's Discuss needs to be resolved G Z: add service id AVP Glenn Z: don't understand how this is expected to work thru anything other than a case where there is a direct connection with a BCC server. Dropping that issue, but that was the issue. ++++++++++++ AAA-URI: Updating 3588 -01- in WGLC, ending Aug 18th; please send comments latest changes are editorial; no known open issues ++++++++++++ Diameter-SIP-03 in WGLC, ending Aug 26th need comments need to analyze comaptibility with draft-sterman-aaa-sip B A: last opportunity to review; this will be deployed widely, so please review. will request SIP & SIPPING WG for review changes: SIP registration -> SIP soft state management -> digest-expected-response AVP updatd: authentication details section Please use the issue tracker: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/ e.g., open issue 14: support for qop=3Dauth-int SIP UA <--> SIP server <---> Diameter server SIP server creates the hash upon indication from DIAMETER server. ++++++++++++ DIAMETER QoS application why?=20 % Authn Authz for QoS req, and Acc for QoS reservations More discussion in NSIS interface to app servers: allow them to dynamically authorize/de-authorize flows propogate knowledge of bearer flows ... Without this: every QoS routing domain deploys an app server =20 with this: subscriber DB <-> diameter cloud <-> app server ^ | v Bearer entity advantages: uniform interface etc lot of open issues ... need to carry authentication for NSIS ??: don't understand your QoS diagrams/model A: please send comments to AAA list of NSIS list J. L: as NSIS WG co-chair:=20 need something like this in NSIS; not sure this fits exactly B A: after negotiation, what if a "big fish" kicks you off J. L: hum interested: several folks not interested: none (inaudible) will talk to Allison M on how to progress individual I-D, sponsored by her; will run WGLC process in AAA WG. this was agreed upon by other chairs and the author. ++++++++++++++++++++++++++ This will/could be the last meeting of the AAA WG. The mailing list will continue to exist. There may be a subsequent DIAMETER maintenance WG. From owner-aaa-wg@merit.edu Wed Sep 1 09:00:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01179 for ; Wed, 1 Sep 2004 09:00:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89EC391234; Wed, 1 Sep 2004 06:16:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 557C8912D9; Wed, 1 Sep 2004 06:16: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 74AE391234 for ; Wed, 1 Sep 2004 06:16:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F64D843F4; Wed, 1 Sep 2004 06:16:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.telenet-ag.de (mail.telenet-ag.de [213.188.99.162]) by segue.merit.edu (Postfix) with ESMTP id 2D3536ED2E for ; Wed, 1 Sep 2004 06:16:38 -0400 (EDT) Received: from notes.ip3k.de (notes.ip3k.de [193.96.234.114]) by mail.telenet-ag.de (8.12.8/8.12.8) with ESMTP id i81AGUEN004578 for ; Wed, 1 Sep 2004 12:16:31 +0200 Subject: [AAA-WG]: RFC3588: Clarification of Session-Id, hosts, realms and FQDNs To: aaa-wg@merit.edu X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: m.hillier@telenet-ag.de Date: Wed, 1 Sep 2004 12:16:10 +0200 X-MIMETrack: Serialize by Router on notes-rhm-1/telenet-ag/de(Release 5.0.11 |July 24, 2002) at 01.09.2004 12:10:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk While studying RFC3588, in particular the sesion-ID AVP (section 8.8) , I am unclear how the first component (up to the first ";") is defined, and how this identity relates to the Origin-Host and Origin-Realm AVPs. "The Session-Id MUST begin with the sender's identity ..." section 4.4.1 gives an example for Session-ID: grump.example.com;..... section 6.1 has some more examples Origin-Host = nas.mno.net and Origin-Realm = mno.net Both Origin-Host and Origin-Realm are of type DiameterIdentity, which is defined in section 4.3 to be Fully Qualified Domain Name also section 6.3.says: "The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and MUST be present in all Diameter messages. This AVP identifies the endpoint that originated the Diameter message. Relay agents MUST NOT modify this AVP. The value of the Origin-Host AVP is guaranteed to be unique within a single host." This refers to the "endpoint" and the uniqueness of "Origin-Host" within a "host". All commands MUST include both Origin-Host and Origin-Realm. Under what circumstances can the "tail-end" of the Origin-Host ever differ from the "Origin-Realm"? Is the "sender's identity" of the Session-Id exactly the Origin-Host? I have searched the archives, but not found any info on this. I fear that I am missing some fundamental concept! Can anybody point me in the right direction? Thanks Mike Hillier ========================= Michael Hillier Telenet AG- Rhein-Main Mobile +49 170 5454 121 M.Hillier@telenet-ag.de From owner-aaa-wg@merit.edu Wed Sep 1 10:06:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15534 for ; Wed, 1 Sep 2004 10:06:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 041FA91339; Wed, 1 Sep 2004 10:05:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A003591338; Wed, 1 Sep 2004 10:05:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63DC591327 for ; Wed, 1 Sep 2004 10:05:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B788844B4; Wed, 1 Sep 2004 10:05:39 -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 51227844A4 for ; Wed, 1 Sep 2004 10:05:38 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i81E5Yj14225; Wed, 1 Sep 2004 17:05:34 +0300 (EET DST) X-Scanned: Wed, 1 Sep 2004 17:02:19 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i81E2JXe031942; Wed, 1 Sep 2004 17:02:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00uRDqkF; Wed, 01 Sep 2004 17:02:19 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i81E2GY26621; Wed, 1 Sep 2004 17:02:16 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 1 Sep 2004 17:02:16 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 1 Sep 2004 17:02:16 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 1 Sep 2004 17:02:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: RFC3588: Clarification of Session-Id, hosts, realms and FQDNs Date: Wed, 1 Sep 2004 17:02:15 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD17832D@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: RFC3588: Clarification of Session-Id, hosts, realms and FQDNs Thread-Index: AcSQDWNwi6IyOrR/Qk6wCNJeUNzc/wAG8EQA From: To: , X-OriginalArrivalTime: 01 Sep 2004 14:02:16.0206 (UTC) FILETIME=[49AA12E0:01C4902C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable m.hillier@telenet-ag.de wrote: > > While studying RFC3588, in particular the sesion-ID AVP > (section 8.8) , I am unclear how the first component (up to > the first ";") is defined, and how this identity relates to > the Origin-Host and Origin-Realm AVPs. "The Session-Id MUST > begin with the sender's identity ..." >=20 > section 4.4.1 gives an example for Session-ID:=20 > grump.example.com;..... >=20 > section 6.1 has some more examples > Origin-Host =3D nas.mno.net and > Origin-Realm =3D mno.net >=20 > Both Origin-Host and Origin-Realm are of type > DiameterIdentity, which is defined in section 4.3 to be Fully > Qualified Domain Name >=20 > also section 6.3.says: "The Origin-Host AVP (AVP Code 264) is > of type DiameterIdentity, and MUST be present in all Diameter > messages. This AVP identifies the endpoint that originated the > Diameter message. Relay agents MUST NOT modify this AVP. The > value of the Origin-Host AVP is guaranteed to be unique within > a single host." >=20 > This refers to the "endpoint" and the uniqueness of > "Origin-Host" within a "host". >=20 > All commands MUST include both Origin-Host and Origin-Realm. >=20 > Under what circumstances can the "tail-end" of the Origin-Host > ever differ from the "Origin-Realm"? There is no requirement that Origin-Realm has to be a suffix=20 of Origin-Host (or Destination-Realm of Destination-Host). So having e.g. host "ap1749.example.net" in realm "example.com"=20 would be OK. And a single Diameter server could serve multiple=20 different realms, but use the same Origin-Host value for all of=20 them. > Is the "sender's identity" of the Session-Id exactly the > Origin-Host? When sending the first message of a particular session (and thus creating a new Session-ID), a node probably puts the same value to Origin-Host. But the value is there to provide uniqueness, so a recipient of a Diameter message can't assume the Session-Id=20 matches the Origin-Host AVP in the same message. Best regards, Pasi From owner-aaa-wg@merit.edu Thu Sep 2 08:11:39 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26531 for ; Thu, 2 Sep 2004 08:11:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BD6169130A; Thu, 2 Sep 2004 08:11:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63C2C9123F; Thu, 2 Sep 2004 08:11: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 149959130C for ; Thu, 2 Sep 2004 08:11:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5EC1845EF; Thu, 2 Sep 2004 08:11:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id C9807845B8 for ; Thu, 2 Sep 2004 08:11:12 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6A44A89876; Thu, 2 Sep 2004 15:10:56 +0300 (EEST) Message-ID: <41370DA8.90204@kolumbus.fi> Date: Thu, 02 Sep 2004 15:10:16 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Re: review of draft-ietf-aaa-diameter-sip-04.txt References: <412E4B3B.4020007@kolumbus.fi> <4131A655.8020908@nokia.com> In-Reply-To: <4131A655.8020908@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 Hi Miguel, and thanks for your quick updates! Some further discussion inline: > "The Diameter SIP application can be used in a SIP environment where an > interface to a AAA infrastructure is required to authenticate and > authorize the usage of SIP resources. This application provides a > limited support for accounting serviers, limited to the Diameter server > being able to provide the addresses of accounting severs to the > Diameter client. " I wonder if it would be useful to provide a recommendation of what AVPs can be carried in an accounting request. Or define a one or two new ones. So that you could get the basic accounting information from SIP at least. Say, caller and callee? Or do you have them already? > This is known because the SIP architecture provides for the existance of > "roles" of servers. For instance, SIP defines the concet of an "outbound > proxy" (it could be SIP server 1). Also, SIP server 1 could be an "edge > proxy" that has knowledge of the topology of the network, so requests > coming from external networks are treated differently from requests that > are coming from internal networks. Ok! > If an external user happens to send a SIP REGISTER request to SIP server > 1, since the user is external (SIP URI belonging to a different domain), > the SIP server will either forward, redirect, or reject this request. I > don't think we need to explain these SIP concepts in this draft. Yes, its fine. >> Question: Can the Diameter server decide that this particular SIP >> request does not require authentication? Can I use just the routing >> aspect of this spec, or do I always need to authenticate too? > > > We never had a requirement to use the routing aspects of this spec, so I > never thought about this scenario. But I believe it is possible. Section > 5.5 (Session attemp) provides an example of a routing scenario. While > this scenario is meant to route incoming requests from other users, I > believe it is applicable for the case you have in mind. Perhaps you could state this somewhere, just in the interest of having orthogonal functions... >> Question: Does the download exchange have to happen in a separate >> roundtrip, or can we do it in parallel with the MAR/MAA? And why do we >> need a separate message, this does not seem to be the case in other >> applications such as NASREQ, all authz information is provided in the >> same return messages? > > First of all, let me start indicating that we need to support two > scenarios (described in Figures 2 and 3). > > If we want to avoid one roundtrip less, then we would need to add the > "please send me the user profile" semantics to MAR/MAA, and I think is > simpler just to keep those semantics in the existing SAR/SAA. > > Another solution would be to use SAR/SAA in steps 13 and 14 of Figure 2, > but we would be changing the semantics of SAR/SAA and mixing them with > MAR/MAA. In this figure 2, MAR clearly has the semantics "please > authenticate/authorize this user with this credentials", whereas SAR > indicates "This SIP server will be serving this user, and please send me > the user profile". > > I wouldn't like to mix semantics more. I see your point. How does this match with what is being done in RADIUS. I can see that you might answer "there is no user profile". However, I suspect vendors will be adding user profile VSAs anyway... >> I'm not sure I understand how the user name would not be >> required. Would this be a global profile change for all users? > > No, this is not the idea. But it is good that you point it out, because > we have already one open issue to this respect: > http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue11 > > I think there is an error here, since the Diameter server ***sends*** > the PPR command to the Diameter client, so obviously, the text "if the > Diameter server requires a User-Name AVP value to process the Diameter > PPR request" does not make sense. It seems to be a copy/paste error. > > So I think the PPR command ought to contain a mandatory User-Name AVP > (currently optional), and cannot contain SIP-AOR AVPs, because the > SIP-AOR URIs will be part of the profile sent in the SIP-User-Data. > > Additionally, I have deleted the paragraph that used to discuss the > absence of User-Name in the PPR command. Great! > I will add yet another reminder that we only support HTTP Digest > authentication. Ok. >> Hmm... capabilities are defined in the network, the user profile is an >> opaque string of data. Does this imply that it isn't possible to use >> equipment from multiple vendors in a networking involving SIP and >> Diameter? Is there an existing 3GPP definition of these profiles? >> What is the reason to avoid the user profile definition, diversity of >> SIP services? Do the SIP nodes have to *act* upon the profile data, or >> is it just somehow passed on? > > > I think this is, by far, the most important issue that we need to solve, > and this is linked to this open issue: > > http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue4 > > So, basically. I believe we need the means to identify the type of > profile that is sent. Of course we don't want to describe here the > contents of the profile, but just list it. > > 3GPP has defined their own user profile in TS 29.228 version 5.8.0 Annex > E. I am not aware of the existence of other user profiles. > > My suggestion: > > - Create a new grouped AVP, by name SIP-User-Profile, that contains two > other AVPs. > - One is a new integer SIP-User-Profile-Type, that contains an integer > describing the type of user profile > - The other is the current SIP-User-Data, i.e., the actual user profile. > > Additionally, we should create another AVP (that allows repetion), by > name SIP-Supported-User-Profiles. The idea is that the Diameter client > can indicate in the SAR command which types of user profiles are > supported, and the Diameter server can send one that suits the Diameter > client. > > How about that? This sounds like a useful compromise between no definition and standard-only definitions. > Further more: I think this requires to open an IANA registration of the > types of user profiles. This is the bit that I don't like, so I am open > to suggestions to avoid this IANA registration process. Why not? > I added the following paragraphs: > > This Diameter SIP application allows a Diameter client to use the > properties of HTTP Digest authentication[RFC2617] by evaluating or > sending to the Diameter server the credentials supplied by a user. When > Section 4 of RFC 2617[RFC2617] discusses HTTP Digest authentication, it > is also applicable to this memo. > > This Diameter SIP application also allows a Diameter client to use the > properties of HTTP Digest authentication using AKA[RFC3310] by > evaluating or sending to the Diameter server the credentials supplied by > a user. Section 5 of RFC 3310[RFC3310] is also applicable to this memo. > > > I don't want to create a dependency on AKA v2, because of two reasons: > first we haven't studied whether we support it straight forward or not. > Second, this will create a normative dependency... and I am not sure of > the fate of AKA v2. I see the problem. You could use an informative reference -- its not like you are depending on those references. Just that you carry Digest in your protocol, and if people want to read on general Digest security issues they should go to . > This document assumes a general architecture where a Home Realm is > composed of one or more nodes implementing Diameter or SIP > functions. Users are issuing SIP request to access SIP resources. For > each particular user, the Home Realm needs to authenticate and > authorize the usage of those resources and/or route to the appropriate > node. We assume that the database containing the user related data is > located outside the SIP node that requires authorization. Data > belonging to different users may be stored in different nodes in the > Home Realm, but we assume that all the data related to a particular > user is stored in a single node. Ok. > Section renamed as suggested. Now this paragraph reads: > > An operator with a large base of installed SIP servers may wish to > minimize the number of round trips between the Diameter client and the > Diameter server. We provide support for a mechanism that allows the > Diameter server to delegate the final authentication check to the SIP > server, saving a round trip. However, it must also noted that this > scenario is only applicable when the authentication of the user does > not use client nonces, since the mechanism is based on the computation > of an expected response in the Diameter server, which makes it > available to the SIP server. Ok. Thanks. --Jari From owner-aaa-wg@merit.edu Thu Sep 2 11:02:44 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10688 for ; Thu, 2 Sep 2004 11:02:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D50419130F; Thu, 2 Sep 2004 11:00:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99EF29130D; Thu, 2 Sep 2004 11:00: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 0666D91310 for ; Thu, 2 Sep 2004 11:00:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 244B084504; Thu, 2 Sep 2004 11:00:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by segue.merit.edu (Postfix) with ESMTP id 7E92784494 for ; Thu, 2 Sep 2004 11:00:23 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i82F0M5S005785 for ; Thu, 2 Sep 2004 17:00:22 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i82F0BfU003903 for ; Thu, 2 Sep 2004 17:00:21 +0200 Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i82F0A8j010714 for ; Thu, 2 Sep 2004 17:00:10 +0200 Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 17:00:10 +0200 Message-ID: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BEF@mchh266e.mchh.siemens.de> From: Belling Thomas To: "AAA (aaa-wg@merit.edu)" Subject: Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Thu, 2 Sep 2004 17:00:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C490FD.8A4882B0" 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_01C490FD.8A4882B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I am new on this email exploder and thus ask to be excused to comment = this famous issue at a very late time. However, it seems that you intend to invetigate this in more detail, = and this seems appropriate. It seems that some usefull features of the applications ID were = forgotten in original analysis, in particular when updating = applications: Suppose you want to update to a new version of an application with = additional mandatory AVPs. Suppose also that the new version obtains a new application ID,=20 (a) Routing: A relay agent may use the application ID to route a request towards a = server that supports the new or old version of the application . This = may be usefull during a transition period when a network is beeing = updated. (b) Capability Negotiation: An updated client capable of using both the new and the old version of = an application could use the Capability exchange to find out if updated = servers are already available I am aware that certain applications add an internal version = negotiation mechanism, which probably provides an alternative solution = for (b). I doubt a full substitute for (a) is possible. From the analysis below it is clear that there may be an inflation of = application IDs due to inheritance issues. Sticking to the view that an application ID is only a last resort = indeed conflicts with the fact that additional AVPs frequentley require = the =B4M=B4bit. It is probably also true that more substantial changes such as changes = to the state machine or new messages are much less frequent than the = addition of mandatory AVPs. The concern about the the bureaucratic overhead could also lead to a = completly different conclusion: Accept that new application IDs will be = frequent and therefore reduce the burden (e.g. expert review) to grant = them. You may apply stricter criteria for more substantial changes = (state machine, messages). This may result in a kind of inheritance in = applictions which is documented in the standardistion texts, but not in = the encoding of application IDs. Regards, Thomas ---------------------------------- Dr. Thomas Belling Siemens AG =20 Sankt-Martin-Str. 76=20 D-81541 M=FCnchen Germany ICM N PG NT ST N1 MCH M 34 307 Tel +49 89 636 75207 Fax +49 89 636 75577 Mobile +49 172 2974678 Email Thomas.Belling@siemens.com ------------------------------------------------------------------------= ---------------------- RFC 3588, Section 1.2.3 describes when a new authentication Application Identifier is needed. Section 1.2.4 describes when new accounting Application Identifiers are required. Included in the list of conditions requiring a new Application-ID is: " - Adding new AVPs to the command, which have the "M" bit set." Given the discussion since the publication of RFC 3588, I now believe = that the above sentence is in error. A new Application-ID should not be required due to addition of AVPs to an application, whether the = mandatory bit is set or not. I am curious what the WG thinks about this. Given that we are just now getting ready to publish Diameter applications as RFCs, it is possible = to correct this mistake. Below I argue that letting this sentence remain = in the spec could prove costly. ANALYSIS Section 1.2.3 states: "An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application." So addition of an AVP by itself does not require a new Application-ID, if the 'M' bit is not set. So what is it about the 'M' bit that changes the situation so fundamentally? Let's review the purpose of the 'M' bit. The purpose of the Mandatory bit was to enable implementations that receive an AVP they do not support to determine whether they can ignore that AVP, or whether a fatal error has occurred. In other words, the purpose of the Mandatory bit was to enable Diameter applications to be extended while maintaining well defined behavior. Given this, if a Diameter application were to be extended with new AVPs without obtaining a new Application ID, what happens? Since no new Application-ID is used, Diameter peers will negotiate capabilities with the existing Application-IDs, oblivious as to whether new 'M' bit AVPs will be used or not. As a result, Diameter = connections will be established all along the path between the Diameter peers. If the new AVPs do not have the 'M' bit set, then a Diameter peer can ignore them, presumably without harm. If the AVPs have the 'M' bit = set, then a Diameter peer doesn't support them, then a fatal error will result -- but Diameter error messages will make it clear what the problem was. What is done on receipt of the error message is implementation dependent -- but one possibility would be to stop = sending the offending AVP to the peer that objected. Note that in most cases, Diameter agents will not care about new AVPs, whether they have the 'M' bit set or not. Relays and Redirects won't care. Proxies might care -- but if they do then they can send their = own fatal errors. Now let us look at what happens if a new Application-ID is required. Since Diameter peers exchange the supported Application-IDs within the CER/CEA exchange, if the new Application-IDs are not supported by one = or more peers along the path, then the Diameter messages won't get routed = to the destination. The end result is the same -- an attempt to send a non-understood AVP with the 'M' bit set will result in an Error-Message coming back, but now the error message will be returned from an intermediary unable to find a Diameter peer to deliver to, rather than from the endpoint peer. This is a bit like the distinction between receiving a "host = unreachable" ICMP message and a "port unreachable" ICMP message. Not a great difference. However, consider the downside to requiring a new Application-ID due to addition of a new mandatory AVP: * Proliferation of Application-IDs. What if it is necessary to extend an application with multiple additional mandatory AVPs? Do we now need a new Application-ID for each potential set of mandatory AVPs? For example, what if we want to extend Diameter EAP with additional wired 802 VLAN attributes as well = as some WLAN attributes and perhaps some filter attributes? Do we need to obtain 3 new application-IDs? Or as an alternative, do we require each application to support versioning? * Additional work in intermediaries. Do intermediaries now need a "Dictionary" of Application-IDs? Why isn't an AVP dictionary = sufficient (if one is needed at all)? * Inheritance effects. Diameter EAP depends on NASREQ. Say I want to extend NASREQ with some additional filter attributes. Does this mean = that both NASREQ and EAP applications need new Application-IDs to support = this? * Bureaucratic overhead. New Application-IDs are allocated by Expert Review. Who is volunteering to be the Expert to "review" all these new Application-IDs? Why isn't review of the new AVP definitions = sufficient? Based on the limited upside and substantial downside of requiring new Application-IDs due to addition of AVPs with the 'M' bit set, my conclusion is that the sentence requiring this in RFC 3588 was an = error. Assuming that the AAA WG agrees with this, then my recommendation is to post an errata to the RFC Editor to this effect. ---------------------------------- Dr. Thomas Belling Siemens AG =20 Sankt-Martin-Str. 76=20 D-81541 M=FCnchen Germany ICM N PG NT ST N1 MCH M 34 307 Tel +49 89 636 75207 Fax +49 89 636 75577 Mobile +49 172 2974678 Email Thomas.Belling@siemens.com ------_=_NextPart_001_01C490FD.8A4882B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new = Application-ID

Dear all,

I am new on this email exploder and = thus ask to be excused to comment this famous issue at a very late = time.
However, it seems that you intend to = invetigate this in more detail, and this seems appropriate.


It seems that some usefull features of = the applications ID were forgotten in original analysis, in particular = when updating applications:

Suppose you want to update to a new = version of an application with additional mandatory AVPs.
Suppose also that the new version = obtains a new application ID,

(a) Routing:
A relay agent may use the application = ID to route a request towards a server that supports the new or old = version of the application . This may be usefull during a transition = period when a network is beeing updated.

(b) Capability Negotiation:
An updated client capable of using = both the new and the old version of an application could use the = Capability exchange to find out if updated servers are already = available


I am aware that certain applications = add an internal version negotiation mechanism, which probably provides = an alternative  solution for (b). I doubt a full substitute for = (a) is possible.



From the analysis below it is clear = that there may be an inflation of application IDs due to inheritance = issues.
Sticking to the view that an = application ID is only a last resort indeed conflicts with the fact = that additional AVPs frequentley require the =B4M=B4bit.

It is probably also true that more = substantial changes such as changes to the state machine or new = messages are much less frequent than the addition of mandatory = AVPs.

The concern about the the bureaucratic = overhead could also lead to a completly different conclusion: Accept = that new application IDs will be frequent and therefore reduce the = burden (e.g. expert review) to grant them. You may apply stricter = criteria for more substantial changes (state machine, messages). This = may result in a kind of inheritance in applictions which is documented = in the standardistion texts, but not in the encoding of application = IDs.



Regards, Thomas


----------------------------------
Dr. Thomas Belling
Siemens = AG          
Sankt-Martin-Str. 76
D-81541 M=FCnchen = Germany
ICM N PG NT ST N1
MCH M 34 307
Tel     +49 = 89 636 75207
Fax     +49 = 89 636 75577
Mobile  +49 172 2974678
Email   = Thomas.Belling@siemens.com





---------------------------------------------------------= -------------------------------------
RFC 3588, Section 1.2.3 = describes when a new authentication Application
Identifier is needed.  = Section 1.2.4 describes when new accounting
Application Identifiers are = required.

Included in the list of = conditions requiring a new Application-ID is:

"   -  = Adding new AVPs to the command, which have the "M" bit = set."

Given the discussion since the = publication of RFC 3588, I now believe that
the above sentence is in = error.  A new Application-ID should not be
required due to addition of = AVPs to an application, whether the mandatory
bit is set or not.

I am curious what the WG thinks = about this.  Given that we are just now
getting ready to publish = Diameter applications as RFCs, it is possible to
correct this mistake.  = Below I argue that letting this sentence remain in
the spec could prove = costly.

ANALYSIS

Section 1.2.3 states:

"An implementation MAY add = arbitrary non-mandatory AVPs to any command
defined in an application, = including vendor-specific AVPs without
needing to define a new = application."

So addition of an AVP by itself = does not require a new
Application-ID, if the 'M' bit = is not set.

So what is it about the 'M' bit = that changes the situation so
fundamentally?

Let's review the purpose of the = 'M' bit.

The purpose of the Mandatory bit = was to enable implementations
that receive an AVP they do not = support to determine whether they can
ignore that AVP, or whether a = fatal error has occurred.

In other words, the purpose of = the Mandatory bit was to enable Diameter
applications to be extended = while maintaining well defined behavior.

Given this, if a Diameter = application were to be extended with new AVPs
without obtaining a new = Application ID, what happens?

Since no new Application-ID is = used, Diameter peers will negotiate
capabilities with the existing = Application-IDs, oblivious as to whether
new 'M' bit AVPs will be used = or not.  As a result, Diameter connections
will be established all along = the path between the Diameter peers.

If the new AVPs do not have the = 'M' bit set, then a Diameter peer can
ignore them, presumably without = harm.  If the AVPs have the 'M' bit set,
then a Diameter peer doesn't = support them, then a fatal error
will result -- but Diameter = error messages will make it clear what the
problem was.  What is done = on receipt of the error message is
implementation dependent -- but = one possibility would be to stop sending
the offending AVP to the peer = that objected.

Note that in most cases, = Diameter agents will not care about new AVPs,
whether they have the 'M' bit = set or not.  Relays and Redirects won't
care.  Proxies might care = -- but if they do then they can send their own
fatal errors.

Now let us look at what happens = if a new Application-ID is required.
Since Diameter peers exchange = the supported Application-IDs within the
CER/CEA exchange, if the new = Application-IDs are not supported by one or
more peers along the path, then = the Diameter messages won't get routed to
the destination.  The end = result is  the same -- an attempt to send a
non-understood AVP with the 'M' = bit set will result in an Error-Message
coming back, but now the error = message will be returned from an
intermediary unable to find a = Diameter peer to deliver to, rather than
from the endpoint peer.

This is a bit like the = distinction between receiving a "host unreachable"
ICMP message and a "port = unreachable" ICMP message.  Not a great
difference.

However, consider the downside = to requiring a new Application-ID due to
addition of a new mandatory = AVP:

* Proliferation of = Application-IDs.

What if it is necessary to = extend an application with multiple
additional mandatory = AVPs?  Do we now need a new Application-ID for
each potential set of mandatory = AVPs?  For example, what if we want to
extend Diameter EAP with = additional wired 802 VLAN attributes as well as
some WLAN attributes and = perhaps some filter attributes?  Do we need to
obtain 3 new = application-IDs?

Or as an alternative, do we = require each application to support
versioning?

* Additional work in = intermediaries.  Do intermediaries now need a
"Dictionary" of = Application-IDs?  Why isn't an AVP dictionary sufficient
(if one is needed at = all)?

* Inheritance effects.  = Diameter EAP depends on NASREQ.  Say I want to
extend NASREQ with some = additional filter attributes.  Does this mean that
both NASREQ and EAP = applications need new Application-IDs to support this?

* Bureaucratic overhead.  = New Application-IDs are allocated by Expert
Review.  Who is = volunteering to be the Expert to "review" all these = new
Application-IDs?  Why = isn't review of the new AVP definitions sufficient?

Based on the limited upside and = substantial downside of requiring new
Application-IDs due to addition = of AVPs with the 'M' bit set, my
conclusion is that the sentence = requiring this in RFC 3588 was an error.
Assuming that the AAA WG agrees = with this, then my recommendation is to
post an errata to the RFC = Editor to this effect.




----------------------------------
Dr. Thomas Belling
Siemens = AG          
Sankt-Martin-Str. 76
D-81541 M=FCnchen = Germany
ICM N PG NT ST N1
MCH M 34 307
Tel     +49 = 89 636 75207
Fax     +49 = 89 636 75577
Mobile  +49 172 = 2974678
Email   = Thomas.Belling@siemens.com



------_=_NextPart_001_01C490FD.8A4882B0-- From owner-aaa-wg@merit.edu Thu Sep 2 11:52:20 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13916 for ; Thu, 2 Sep 2004 11:52:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2AD4691325; Thu, 2 Sep 2004 11:51:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5BD29134B; Thu, 2 Sep 2004 11:51: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 4EA9691325 for ; Thu, 2 Sep 2004 11:51:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B989845D8; Thu, 2 Sep 2004 11:51:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id D6AC484604 for ; Thu, 2 Sep 2004 11:51:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i82FiD731103; Thu, 2 Sep 2004 08:44:14 -0700 Date: Thu, 2 Sep 2004 08:44:13 -0700 (PDT) From: Bernard Aboba To: Belling Thomas Cc: "AAA (aaa-wg@merit.edu)" Subject: Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID In-Reply-To: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BEF@mchh266e.mchh.siemens.de> Message-ID: References: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BEF@mchh266e.mchh.siemens.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE > (a) Routing: > A relay agent may use the application ID to route a request towards a ser= ver > that supports the new or old version of the application. This may be usef= ul > during a transition period when a network is beeing updated. For this to work, intermediaries in the path first have to be updated to support both the old and new versions. Otherwise, the request will be rejected before it gets to the "new" server. > (b) Capability Negotiation: > An updated client capable of using both the new and the old > version of an application could use the Capability exchange to find out > if updated servers are already available Capabilities negotiation only works on a hop-by-hop basis, so it can't be used to discover if updated servers are available, only updated intermediaries. The client has to send a packet to discover if updated servers exist. > I am aware that certain applications add an internal version > negotiation mechanism, which probably provides an alternative solution > for (b). I doubt a full substitute for (a) is possible. Versioning can only ensure that the client and server speak the most advanced version that they both support. Application-ID routing can help a client route a request to a server supporting the desired version, if such a server exists. > Sticking to the view that an application ID is only a last resort indeed > conflicts with the fact that additional AVPs frequently require the > =B4M=B4bit. Application-IDs are a last resort because of their intrinsic limitations. Applications which have discrete "versions" can be handled gracefully by allocating a new Application-ID. However, in the case of applications which may have a number of "extensions" the number of required Application-IDs (and associated intermediary upgrades) gets out of hand quickly. > It is probably also true that more substantial changes such as changes > to the state machine or new messages are much less frequent than the > addition of mandatory AVPs. Yes, I think that's true. > The concern about the the bureaucratic overhead could also lead to a > completely different conclusion: Accept that new application IDs will be > frequent and therefore reduce the burden (e.g. expert review) to grant > them. You may apply stricter criteria for more substantial changes > (state machine, messages). This may result in a kind of inheritance in > applictions which is documented in the standardistion texts, but not in > the encoding of application IDs. Application-IDs are already allocated by expert review. Are you suggesting that something less should be required (First Come, First Served)? Since there are already stricter allocation requirements for new commands, mandatory AVPs, etc. it's not clear to me that we need to increase the difficulty of allocating Application-IDs depending on the underlying reason for the request. From owner-aaa-wg@merit.edu Thu Sep 2 12:36:56 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16540 for ; Thu, 2 Sep 2004 12:36:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9519A9131E; Thu, 2 Sep 2004 12:36:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A2949130D; Thu, 2 Sep 2004 12:36:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C050391319 for ; Thu, 2 Sep 2004 12:35:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CA5784546; Thu, 2 Sep 2004 12:35:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by segue.merit.edu (Postfix) with ESMTP id F243E84533 for ; Thu, 2 Sep 2004 12:35:31 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i82GZS5S028695; Thu, 2 Sep 2004 18:35:28 +0200 Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i82GZ4fU006562; Thu, 2 Sep 2004 18:35:14 +0200 Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Sep 2004 18:34:51 +0200 Message-ID: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF4@mchh266e.mchh.siemens.de> From: Belling Thomas To: "'Bernard Aboba'" , "AAA (aaa-wg@merit.edu)" Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Thu, 2 Sep 2004 18:35:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Dear Bernard, I indeed wanted to discuss if having many appication IDs has that many negative impacts. > Application-IDs are already allocated by expert review. Are you > suggesting that something less should be required (First Come, First > Served)? Due to concerns about the administrative overhaed I suggested decreasing the burden for appication IDs ias a possible solution. > Since there are already stricter allocation requirements for new commands, > mandatory AVPs, etc. it's not clear to me that we need to increase the > difficulty of allocating Application-IDs depending on the underlying > reason for the request. This may be seen as arguments that an Application ID does not require strict criteria. The more interesting issue probably is the administrative burden in a network. > > (a) Routing: > > A relay agent may use the application ID to route a request towards a ser= ver > > that supports the new or old version of the application. This may be usef= ul > > during a transition period when a network is beeing updated. > > For this to work, intermediaries in the path first have to be updated > to support both the old and new versions. Otherwise, the request will > be rejected before it gets to the "new" server. Routing table may also be updated due to information from a capability exchange, but this has certain limitions because the capability exchange in only hop-by-hop. By the way: Propagating information by relay agents is nowhere described, but I assume it is not ruled out either. The requirement would be that a CER is also allowed for an existing connection, not only when establishing it. > Application-IDs are a last resort because of their intrinsic limitations. > Applications which have discrete "versions" can be handled gracefully by > allocating a new Application-ID. However, in the case of applications > which may have a number of "extensions" the number of required > Application-IDs (and associated intermediary upgrades) gets out of hand quickly. This is basically the old argument that there may be many application IDs. However I agree that this scenario may leed to extremly high numbers. It may depend on the application if many disctrete extensions are anticipated. This may indeed be a reason for extra negotiation mechanisms within applications. Best regards, Thomas From owner-aaa-wg@merit.edu Thu Sep 2 13:07:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19087 for ; Thu, 2 Sep 2004 13:07:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E4B391314; Thu, 2 Sep 2004 13:07:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A89891311; Thu, 2 Sep 2004 13:07: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 C9C4791311 for ; Thu, 2 Sep 2004 13:07:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A2F7C845D4; Thu, 2 Sep 2004 13:07:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 1D6086EE6B for ; Thu, 2 Sep 2004 13:07:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i82H0KD03265; Thu, 2 Sep 2004 10:00:20 -0700 Date: Thu, 2 Sep 2004 10:00:20 -0700 (PDT) From: Bernard Aboba To: Belling Thomas Cc: "AAA (aaa-wg@merit.edu)" Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID In-Reply-To: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF4@mchh266e.mchh.siemens.de> Message-ID: References: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF4@mchh266e.mchh.siemens.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > This is basically the old argument that there may be many application IDs. > However I agree that this scenario may lead to extremly high numbers. > It may depend on the application if many disctrete extensions > are anticipated. This may indeed be a reason for extra negotiation > mechanisms within applications. In RADEXT WG we are looking at WLAN extensions for things like VLANs, re-direction, etc. There could easily be half a dozen or more of these extensions. They often need to carry the 'M' bit because they affect security and cannot be ignored if not understood by the NAS. Under RFC 3588, it is not clear how to extend Diameter EAP to handle this. Some vendors will support some extensions and not others, so a "versioning" mechanism does not seem feasible. Neither does allocating a new Application-ID for each combination of AVPs with the 'M' bit set. For example, for half a dozen new 'M' bit AVPs, we would be talking about (6 1) + (6 2) + (6 3) + (6 4) + (6 5) + (6 6) = 6 + 15 + 20 + 15 + 6 + 1 = 63 Application-IDs. As described in the analysis, in this particular case, there does not seem to be a downside to adding a new IETF Standard AVP with the 'M' bit set without allocating a new Application-ID. If the AVP is supported, it will work; if it isn't supported, an error message will result, but that is what is desired. IMHO this issue is fairly major, since it limits the ability of Diameter to continue evolving. From owner-aaa-wg@merit.edu Thu Sep 2 16:18:57 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04148 for ; Thu, 2 Sep 2004 16:18:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86FCB9124B; Thu, 2 Sep 2004 16:18:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB28091311; Thu, 2 Sep 2004 16:18: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 5F9099124B for ; Thu, 2 Sep 2004 16:18:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D0DB84530; Thu, 2 Sep 2004 16:18:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by segue.merit.edu (Postfix) with ESMTP id 9CB5E84420 for ; Thu, 2 Sep 2004 16:18:08 -0400 (EDT) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.1/8.13.1) with ESMTP id i82KHt3U079232; Thu, 2 Sep 2004 16:17:55 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.1/8.13.1/Submit) id i82KHt9D079231; Thu, 2 Sep 2004 16:17:55 -0400 (EDT) (envelope-from barney) Date: Thu, 2 Sep 2004 16:17:55 -0400 From: Barney Wolff To: Bernard Aboba Cc: Belling Thomas , "AAA (aaa-wg@merit.edu)" Subject: Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Message-ID: <20040902201755.GA78013@pit.databus.com> References: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF4@mchh266e.mchh.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.44 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Sep 02, 2004 at 10:00:20AM -0700, Bernard Aboba wrote: > > Under RFC 3588, it is not clear how to extend Diameter EAP to handle this. > Some vendors will support some extensions and not others, so a "versioning" > mechanism does not seem feasible. Neither does allocating a new Application-ID > for each combination of AVPs with the 'M' bit set. For example, for half > a dozen new 'M' bit AVPs, we would be talking about (6 1) + (6 2) + (6 3) > + (6 4) + (6 5) + (6 6) = 6 + 15 + 20 + 15 + 6 + 1 = 63 Application-IDs. > > As described in the analysis, in this particular case, there does not seem > to be a downside to adding a new IETF Standard AVP with the 'M' bit set > without allocating a new Application-ID. If the AVP is supported, it > will work; if it isn't supported, an error message will result, but that > is what is desired. > > IMHO this issue is fairly major, since it limits the ability of Diameter > to continue evolving. It strikes me as an implementor that having 6 AVPs that might be supported individually in any combination (which is 2^6=64, counting "none" :) is a nightmare. Allowing this scattershot approach seems impractical and merely pushes the pain of deciding which combinations of AVPs make sense onto the implementors rather than the RFC writers. Interoperability should mean something more than just getting a reject. At the very least, sets of AVPs that are used for some "feature" MUST all be implemented or all be not implemented, if the software is to avoid the combinatorial explosion. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-aaa-wg@merit.edu Thu Sep 2 22:37:00 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02731 for ; Thu, 2 Sep 2004 22:37:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7558391252; Thu, 2 Sep 2004 22:36:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D87C691253; Thu, 2 Sep 2004 22:36: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 84FA99132B for ; Thu, 2 Sep 2004 22:36:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C6B084681; Thu, 2 Sep 2004 22:36:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id D62038467E for ; Thu, 2 Sep 2004 22:36:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i832TNR03422; Thu, 2 Sep 2004 19:29:23 -0700 Date: Thu, 2 Sep 2004 19:29:23 -0700 (PDT) From: Bernard Aboba To: Barney Wolff Cc: "AAA (aaa-wg@merit.edu)" Subject: Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID In-Reply-To: <20040902201755.GA78013@pit.databus.com> Message-ID: References: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF4@mchh266e.mchh.siemens.de> <20040902201755.GA78013@pit.databus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > It strikes me as an implementor that having 6 AVPs that might be supported > individually in any combination (which is 2^6=64, counting "none" :) > is a nightmare. Allowing this scattershot approach seems impractical > and merely pushes the pain of deciding which combinations of AVPs make > sense onto the implementors rather than the RFC writers. Interoperability > should mean something more than just getting a reject. > > At the very least, sets of AVPs that are used for some "feature" MUST all > be implemented or all be not implemented, if the software is to avoid > the combinatorial explosion. I think a good deal of what you say makes sense. And in practice, the current Diameter standards-to-be and RADIUS RFCs are structured like this. For example, those NASes that support ARAP typically support all the ARAP attributes in RFC 2869; those that support EAP support all the EAP attributes in RFC 3579; WLAN APs typically implement all of RFC 3580; NASes supporting IPv6 typically support all of RFC 3162, etc. The same can be said of "bundles of functionality" such as Diameter SIP/RADIUS Sterman. But I'm not clear that all the "extensions" proposed in RADEXT WG fit into this paradigm. Perhaps that is itself a problem. From owner-aaa-wg@merit.edu Fri Sep 3 03:00:18 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02575 for ; Fri, 3 Sep 2004 03:00:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A74B591335; Fri, 3 Sep 2004 02:59:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 745679133C; Fri, 3 Sep 2004 02:59: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 9A6EB91335 for ; Fri, 3 Sep 2004 02:59:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9753884693; Fri, 3 Sep 2004 02:59:34 -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 272DF846EB for ; Fri, 3 Sep 2004 02:59:26 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i836vf115820; Fri, 3 Sep 2004 09:57:41 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 09:53:59 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i836rxJH027664; Fri, 3 Sep 2004 09:53:59 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00FLEI71; Fri, 03 Sep 2004 09:53:57 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i836rvS08815; Fri, 3 Sep 2004 09:53:57 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 09:53:57 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 09:53:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 09:53:56 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D089221@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRXyJsoUC3Ef1xQ2mO9/z66/AlnQAIw6Uw From: To: , Cc: X-OriginalArrivalTime: 03 Sep 2004 06:53:57.0299 (UTC) FILETIME=[C8BF9030:01C49182] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, > I think a good deal of what you say makes sense. And in practice, the > current Diameter standards-to-be and RADIUS RFCs are=20 > structured like this. >=20 > For example, those NASes that support ARAP typically support all the > ARAP attributes in RFC 2869; those that support EAP support all the = EAP > attributes in RFC 3579; WLAN APs typically implement all of RFC 3580; > NASes supporting IPv6 typically support all of RFC 3162, etc. >=20 > The same can be said of "bundles of functionality" such as Diameter > SIP/RADIUS Sterman. >=20 > But I'm not clear that all the "extensions" proposed in RADEXT WG fit = into > this paradigm. Perhaps that is itself a problem. In my opinion, a Diameter Application should be a set of functionalities = that are not yet currently defined by existing applications. Therefore bundling new command codes or new sets of mandatory AVPs would qualify as a new application, in my opinion. Adding single codes or single = mandatory AVPs seems like a bad way to go, especially if you think of deployment and operation of AAA services. That being said, I think if we want to see wide-scale deployments of the new RADIUS extensions, defining them in bundles makes a lot more sense, otherwise implementations may implement one new attribute while another may not, which of course will lead to interoperability failures. John From owner-aaa-wg@merit.edu Fri Sep 3 03:04:42 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02769 for ; Fri, 3 Sep 2004 03:04:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 30A3791359; Fri, 3 Sep 2004 03:03:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1A0991367; Fri, 3 Sep 2004 03:03: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 80E6591359 for ; Fri, 3 Sep 2004 03:03:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C840846B0; Fri, 3 Sep 2004 03:02:24 -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 9E99484671 for ; Fri, 3 Sep 2004 03:02:14 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8371R121526; Fri, 3 Sep 2004 10:01:27 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 09:57:43 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i836vhML001383; Fri, 3 Sep 2004 09:57:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 002eYuw4; Fri, 03 Sep 2004 09:57:41 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i836vVS10368; Fri, 3 Sep 2004 09:57:31 +0300 (EET DST) Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 09:57:22 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 09:57:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 09:57:21 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D089222@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRC1AT4iKvJhPXQruEw6iug/ZLKgAd5RRA From: To: , , X-OriginalArrivalTime: 03 Sep 2004 06:57:20.0534 (UTC) FILETIME=[41E2C360:01C49183] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Thomas, > Due to concerns about the administrative overhaed I suggested=20 > decreasing the burden for appication IDs ias a possible solution. What would be your model for this? [some text cut] > This is basically the old argument that there may be many application = IDs. > However I agree that this scenario may leed to extremly high numbers. > It may depend on the application if many disctrete extensions=20 > are anticipated. This may indeed be a reason for extra=20 > negotiation mechanisms within applications. Right now, there is no standard way to do extended negotiation. If = there were one, we could could use this to negotiation sub-feature support. = However, as there is no solution at present to do this. Do you feel that this = feature is needed? =20 John From owner-aaa-wg@merit.edu Fri Sep 3 03:53:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05245 for ; Fri, 3 Sep 2004 03:53:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 57EE291253; Fri, 3 Sep 2004 03:53:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 216479133B; Fri, 3 Sep 2004 03:53: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 53F6591336 for ; Fri, 3 Sep 2004 03:53:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 382906EDFB; Fri, 3 Sep 2004 03:53:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 1E2B36EDFA for ; Fri, 3 Sep 2004 03:53:30 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i837rST12474 for ; Fri, 3 Sep 2004 10:53:28 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 10:49:45 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i837njRU031221 for ; Fri, 3 Sep 2004 10:49:45 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00yDTuCN; Fri, 03 Sep 2004 10:49:44 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i837niS06018 for ; Fri, 3 Sep 2004 10:49:44 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 10:49:40 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 10:49:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 10:49:38 +0300 Message-ID: <78577AECEB6226409F9F4BFB53FE183708F716@esebe054.ntc.nokia.com> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRD5NSVIR1p2EtRZqSrLJdCBVXBwAeaqaw From: To: X-OriginalArrivalTime: 03 Sep 2004 07:49:39.0069 (UTC) FILETIME=[909932D0:01C4918A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > As described in the analysis, in this particular case, there=20 > does not seem to be a downside to adding a new IETF Standard AVP with = the=20 > 'M' bit set without allocating a new Application-ID. If the AVP > is supported, it will work; if it isn't supported, an error message = will=20 > result, but that is what is desired. One potential downside is the performance of the implementation. If a peer receives a message with unsupported application-id it can be sure right away that it can't support the message. If a peer receives a message with supported application-id that has mandatory AVP it does not support, the peer must parse the whole message before it finds out it must reject the message. I'm not sure if this is a problem in practise. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Bernard Aboba > Sent: 02 September, 2004 20:00 > To: Belling Thomas > Cc: AAA (aaa-wg@merit.edu) > Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs=20 > requires new > A pplication-ID >=20 >=20 > > This is basically the old argument that there may be many=20 > application IDs. > > However I agree that this scenario may lead to extremly=20 > high numbers. > > It may depend on the application if many disctrete extensions > > are anticipated. This may indeed be a reason for extra negotiation > > mechanisms within applications. >=20 > In RADEXT WG we are looking at WLAN extensions for things like VLANs, > re-direction, etc. There could easily be half a dozen or=20 > more of these > extensions. They often need to carry the 'M' bit because they affect > security and cannot be ignored if not understood by the NAS. >=20 > Under RFC 3588, it is not clear how to extend Diameter EAP to=20 > handle this. > Some vendors will support some extensions and not others, so=20 > a "versioning" > mechanism does not seem feasible. Neither does allocating a=20 > new Application-ID > for each combination of AVPs with the 'M' bit set. For=20 > example, for half > a dozen new 'M' bit AVPs, we would be talking about (6 1) +=20 > (6 2) + (6 3) > + (6 4) + (6 5) + (6 6) =3D 6 + 15 + 20 + 15 + 6 + 1 =3D 63=20 > Application-IDs. >=20 > As described in the analysis, in this particular case, there=20 > does not seem > to be a downside to adding a new IETF Standard AVP with the=20 > 'M' bit set > without allocating a new Application-ID. If the AVP is supported, it > will work; if it isn't supported, an error message will=20 > result, but that > is what is desired. >=20 > IMHO this issue is fairly major, since it limits the ability=20 > of Diameter > to continue evolving. >=20 >=20 From owner-aaa-wg@merit.edu Fri Sep 3 04:19:39 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06770 for ; Fri, 3 Sep 2004 04:19:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DF0D9135C; Fri, 3 Sep 2004 04:18:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 530F091361; Fri, 3 Sep 2004 04:18: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 30C899135C for ; Fri, 3 Sep 2004 04:18:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 130546ED3F; Fri, 3 Sep 2004 04:18:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 518CA6ED93 for ; Fri, 3 Sep 2004 04:18:37 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 10:17:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 10:17:15 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02601519AAF@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRC1AT4iKvJhPXQruEw6iug/ZLKgAd5RRAAAIAQ4A= From: "MORAND Lionel RD-CORE-ISS" To: , , , X-OriginalArrivalTime: 03 Sep 2004 08:17:17.0856 (UTC) FILETIME=[6D500200:01C4918E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, >=20 > Right now, there is no standard way to do extended=20 > negotiation. If there were one, we could could use this to=20 > negotiation sub-feature support. However, as there is no=20 > solution at present to do this. Do you feel that this=20 > feature is needed? =20 >=20 From my point of view, the problem of versioning has appeared due to the "unclear" specification of the extensibility mechanism (i.e. adding new AVP with the M-bit set). To avoid the need for a new application-ID when a new feature is added to an existing Diameter application, a solution was to define versions of the same application and to specify a specific version negotiation at the application layer. But this solution was forced by the "new M-bit AVP -> new application-ID" dogma. If the base protocol specification clarifies that the addition of new M-bit AVPs doesn't require a new application-ID and the approriate error handling for unsupported AVPs (as proposed by Bernard), this will deprecate the use of version. Lionel From owner-aaa-wg@merit.edu Fri Sep 3 05:33:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10717 for ; Fri, 3 Sep 2004 05:33:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD37391255; Fri, 3 Sep 2004 05:31:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A288E91336; Fri, 3 Sep 2004 05:31: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 6A5B391255 for ; Fri, 3 Sep 2004 05:31:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B9A76EC51; Fri, 3 Sep 2004 05:31:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from twmail.Texworld.com (texworld.com [203.129.254.200]) by segue.merit.edu (Postfix) with ESMTP id A63FE6EC8C for ; Fri, 3 Sep 2004 05:31:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Date: Fri, 3 Sep 2004 15:04:39 +0530 Message-ID: Thread-Index: AcSRmTt5Ufsyq6Y0TFqwbifN5hcYRg== From: "Ninoo Pauls" To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 From owner-aaa-wg@merit.edu Fri Sep 3 05:37:03 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10853 for ; Fri, 3 Sep 2004 05:37:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F0FB99125B; Fri, 3 Sep 2004 05:36:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6655A91259; Fri, 3 Sep 2004 05:36: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 2769C91258 for ; Fri, 3 Sep 2004 05:35:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0DC3D6EE2E; Fri, 3 Sep 2004 05:35: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 25CDD6EC8C for ; Fri, 3 Sep 2004 05:35:34 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i839ZW124487; Fri, 3 Sep 2004 12:35:32 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 12:31:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i839V2bp012328; Fri, 3 Sep 2004 12:31:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 007wpjq7; Fri, 03 Sep 2004 12:31:00 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i839UwY27276; Fri, 3 Sep 2004 12:30:58 +0300 (EET DST) Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 12:30:56 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 12:30:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 12:30:55 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D089229@esebe056.ntc.nokia.com> Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRC1AT4iKvJhPXQruEw6iug/ZLKgAd5RRAAAIAQ4AAA2ci8A== From: To: , X-OriginalArrivalTime: 03 Sep 2004 09:30:55.0195 (UTC) FILETIME=[B64072B0:01C49198] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Lionel, > > Right now, there is no standard way to do extended=20 > > negotiation. If there were one, we could could use this to=20 > > negotiation sub-feature support. However, as there is no=20 > > solution at present to do this. Do you feel that this=20 > > feature is needed? =20 > >=20 >=20 > From my point of view, the problem of versioning has appeared due to = the > "unclear" specification of the extensibility mechanism (i.e. adding = new > AVP with the M-bit set). To avoid the need for a new application-ID = when > a new feature is added to an existing Diameter application, a solution > was to define versions of the same application and to specify a = specific > version negotiation at the application layer. But this solution was > forced by the "new M-bit AVP -> new application-ID" dogma. >=20 > If the base protocol specification clarifies that the addition of new > M-bit AVPs doesn't require a new application-ID and the approriate = error > handling for unsupported AVPs (as proposed by Bernard), this will > deprecate the use of version. According to our AD, adding new mandatory AVPs causes interoperability problems, therefore the current text remains as is. If we would like=20 to modify that behavior, we most likely need to document the new = functionality in an RFC. John From owner-aaa-wg@merit.edu Fri Sep 3 06:07:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13658 for ; Fri, 3 Sep 2004 06:07:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AF859125C; Fri, 3 Sep 2004 06:06:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 386CC91258; Fri, 3 Sep 2004 06: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 9768791258 for ; Fri, 3 Sep 2004 06:06:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 724AE6EDBB; Fri, 3 Sep 2004 06:06:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 6501A6EE3D for ; Fri, 3 Sep 2004 06:06:54 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 12:06:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE : RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 12:06:45 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02601519B59@ftrdmel2.rd.francetelecom.fr> Thread-Topic: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRC1AT4iKvJhPXQruEw6iug/ZLKgAd5RRAAAIAQ4AAA2ci8AAA9Pog From: "MORAND Lionel RD-CORE-ISS" To: , X-OriginalArrivalTime: 03 Sep 2004 10:06:46.0524 (UTC) FILETIME=[B88B33C0:01C4919D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, > According to our AD, adding new mandatory AVPs causes=20 > interoperability problems, therefore the current text remains=20 > as is. If we would like=20 > to modify that behavior, we most likely need to document the=20 > new functionality in an RFC. My mistake! You're right. But the purpose of the new document will be the same: clarify the issues, and update RFC 3588. And I think that Bernard is currently drafting something. Lionel=20 From owner-aaa-wg@merit.edu Fri Sep 3 06:18:52 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14712 for ; Fri, 3 Sep 2004 06:18:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCF9791257; Fri, 3 Sep 2004 06:15:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 984779125A; Fri, 3 Sep 2004 06:15: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 50FB591257 for ; Fri, 3 Sep 2004 06:15:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28CFF6ED3F; Fri, 3 Sep 2004 06:15:36 -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 E26586ECCC for ; Fri, 3 Sep 2004 06:15:34 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83AFX116765; Fri, 3 Sep 2004 13:15:33 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 13:10:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i83AARrV005211; Fri, 3 Sep 2004 13:10:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 005u3Sl4; Fri, 03 Sep 2004 13:10:27 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83AAPY27123; Fri, 3 Sep 2004 13:10:25 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 13:10:25 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 13:10:23 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 13:10:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 13:10:23 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D089233@esebe056.ntc.nokia.com> Thread-Topic: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRC1AT4iKvJhPXQruEw6iug/ZLKgAd5RRAAAIAQ4AAA2ci8AAA9PogAAB0zDA= From: To: , X-OriginalArrivalTime: 03 Sep 2004 10:10:23.0772 (UTC) FILETIME=[3A089DC0:01C4919E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lionel, >=20 > > According to our AD, adding new mandatory AVPs causes=20 > > interoperability problems, therefore the current text remains=20 > > as is. If we would like=20 > > to modify that behavior, we most likely need to document the=20 > > new functionality in an RFC. >=20 > My mistake! You're right. > But the purpose of the new document will be the same: clarify the > issues, and update RFC 3588. And I think that Bernard is currently > drafting something. Yes, this is something that we have been discussing as AAA chairs. John From owner-aaa-wg@merit.edu Fri Sep 3 07:04:01 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18573 for ; Fri, 3 Sep 2004 07:04:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75B1291248; Fri, 3 Sep 2004 07:01:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 495419125A; Fri, 3 Sep 2004 07:01: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 A37E191248 for ; Fri, 3 Sep 2004 07:01:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BE2D6ECD6; Fri, 3 Sep 2004 07:01:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by segue.merit.edu (Postfix) with ESMTP id 0AF3D5AFCB for ; Fri, 3 Sep 2004 07:01:35 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i83B1Xec014752; Fri, 3 Sep 2004 13:01:33 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i83B11fU001999; Fri, 3 Sep 2004 13:01:11 +0200 Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i83B0e8j005702; Fri, 3 Sep 2004 13:00:50 +0200 Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Sep 2004 13:00:37 +0200 Message-ID: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF8@mchh266e.mchh.siemens.de> From: Belling Thomas To: "'john.loughney@nokia.com'" , lionel.morand@francetelecom.com, aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 13:00:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all There seems to be an understanding in the group that a new application = ID is mandated if a new AVP mith =B4M=B4Flag is added. However, the text in RFC 3556 seems to indicate it is optional: " Should a new Diameter usage scenario find itself unable to 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: - Adding new AVPs to the command, which have the "M" bit set. " This seems to be in line with explanatory text for the =B4M`bit, that = also speaks about AVPs without =B4M=B4bits outside applications: " The 'M' Bit, known as the Mandatory bit, indicates whether = support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation = agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs. The 'M' bit MUST be set according to the rules defined for the = AVP containing it. >>> In order to preserve interoperability, a = Diameter implementation MUST be able to exclude from a Diameter message = any Mandatory AVP which is neither defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in which it appears. <<< ... Diameter implementations are required to support all Mandatory AVPs which are allowed by the message's formal syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing the message. " If the understanding within the group is a new application ID for the = AVPs with the =B4M=B4bit is mandatory, (the below interoperability = concerns may justify that), one could improve the wording. Is that = something for the errata? Or is it preferable to keep the wording as it is, and grant a certain = degree of freedom fpr application designers in this difficult field? Thomas > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 > On Behalf Of john.loughney@nokia.com > Sent: Friday, September 03, 2004 11:31 AM > To: lionel.morand@francetelecom.com; aaa-wg@merit.edu > Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit=20 > AVPs requires new A pplication-ID >=20 >=20 > Lionel, >=20 > > > Right now, there is no standard way to do extended=20 > > > negotiation. If there were one, we could could use this to=20 > > > negotiation sub-feature support. However, as there is no=20 > > > solution at present to do this. Do you feel that this=20 > > > feature is needed? =20 > > >=20 > >=20 > > From my point of view, the problem of versioning has=20 > appeared due to the > > "unclear" specification of the extensibility mechanism=20 > (i.e. adding new > > AVP with the M-bit set). To avoid the need for a new=20 > application-ID when > > a new feature is added to an existing Diameter application,=20 > a solution > > was to define versions of the same application and to=20 > specify a specific > > version negotiation at the application layer. But this solution was > > forced by the "new M-bit AVP -> new application-ID" dogma. > >=20 > > If the base protocol specification clarifies that the=20 > addition of new > > M-bit AVPs doesn't require a new application-ID and the=20 > approriate error > > handling for unsupported AVPs (as proposed by Bernard), this will > > deprecate the use of version. >=20 > According to our AD, adding new mandatory AVPs causes = interoperability > problems, therefore the current text remains as is. If we would like = > to modify that behavior, we most likely need to document the > new functionality > in an RFC. >=20 > John >=20 From owner-aaa-wg@merit.edu Fri Sep 3 07:39:35 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20674 for ; Fri, 3 Sep 2004 07:39:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22AAA91259; Fri, 3 Sep 2004 07:38:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4CCC9124A; Fri, 3 Sep 2004 07:38: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 48E7491258 for ; Fri, 3 Sep 2004 07:38:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F4B184431; Fri, 3 Sep 2004 07:38:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 6E23A8440A for ; Fri, 3 Sep 2004 07:38:54 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2D6798986C; Fri, 3 Sep 2004 14:38:44 +0300 (EEST) Message-ID: <4138579B.9050003@kolumbus.fi> Date: Fri, 03 Sep 2004 14:38:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Barney Wolff , "AAA (aaa-wg@merit.edu)" Subject: Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID References: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF4@mchh266e.mchh.siemens.de> <20040902201755.GA78013@pit.databus.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>It strikes me as an implementor that having 6 AVPs that might be supported >>individually in any combination (which is 2^6=64, counting "none" :) >>is a nightmare. Allowing this scattershot approach seems impractical >>and merely pushes the pain of deciding which combinations of AVPs make >>sense onto the implementors rather than the RFC writers. Interoperability >>should mean something more than just getting a reject. >> >>At the very least, sets of AVPs that are used for some "feature" MUST all >>be implemented or all be not implemented, if the software is to avoid >>the combinatorial explosion. > > > I think a good deal of what you say makes sense. And in practice, the > current Diameter standards-to-be and RADIUS RFCs are structured like this. > > For example, those NASes that support ARAP typically support all the > ARAP attributes in RFC 2869; those that support EAP support all the EAP > attributes in RFC 3579; WLAN APs typically implement all of RFC 3580; > NASes supporting IPv6 typically support all of RFC 3162, etc. > > The same can be said of "bundles of functionality" such as Diameter > SIP/RADIUS Sterman. > > But I'm not clear that all the "extensions" proposed in RADEXT WG fit into > this paradigm. Perhaps that is itself a problem. I'm not completely convinced yet that the combinatorial explosion is a real problem. The first question to ask is whether the functions are orthogonal or if there's some need that the peers must consider them in relation to each to other. For some of the new attribute work, it looks to me that they are orthogonal. For instance, I don't see a reason why a geographic location attribute processing would affect bandwidth attributes. If this is true, it means that good implementations do not get any more complex because they support combinatorial use of these attributes. Testing-wise it may bring additional test cases. Then again, even if you define all the attributes in the same RFC does not remove the possibility that they are actually included/excluded on an individual basis, so it seems like The only issue is how to find out what the other side supports. I see three possibilities: (1) Not negotiable. You do it or I will not work with you. An error leads to disconnect. (2) Trial-and-error. The algorithm is simple, but if you had a lot of attributes the other side did not support, there could be a lot of iterations. (3) Fine-grained (beyond RFC 3588) and e2e capabilities negotiation. You'll notice that the above applies irrespective of the granularity of the RFCs; if all new attributes are grouped to one RFC then alternative 2 converges faster, however... Note also the alternatives present a trade-off between convergence time and complexity. I would not necessarily jump on the fine-grained capabilities negotiation before we have some proof that the other alternatives present a real practical problem. On the other hand, if there is some reason to believe that the functions somehow depend on each other, then we may have a more interesting problem at our hands. Then it should be clear that they should go to the same RFC if at all possible. The other question is which of the proposed attributes actually are mandatory. Not all of them are. Summing up, I do not feel that the use of M=1 on IETF-defined new standard attributes is a problem. But we should design the RFCs so that a logical group of functions goes into one RFC without too many dependencies to other RFCs. --Jari From owner-aaa-wg@merit.edu Fri Sep 3 07:59:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21889 for ; Fri, 3 Sep 2004 07:59:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53E379124A; Fri, 3 Sep 2004 07:59:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1950891262; Fri, 3 Sep 2004 07:59: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 7E27F91258 for ; Fri, 3 Sep 2004 07:59:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7598784450; Fri, 3 Sep 2004 07:59:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by segue.merit.edu (Postfix) with ESMTP id C85D38444E for ; Fri, 3 Sep 2004 07:59:25 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i83BxLec001437; Fri, 3 Sep 2004 13:59:21 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i83BwpfU005585; Fri, 3 Sep 2004 13:59:01 +0200 Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i83Bwe8j023270; Fri, 3 Sep 2004 13:58:51 +0200 Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Sep 2004 13:58:37 +0200 Message-ID: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BF9@mchh266e.mchh.siemens.de> From: Belling Thomas To: "'john.loughney@nokia.com'" , Belling Thomas , aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 13:58:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, answers inline. Thomas > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Friday, September 03, 2004 8:57 AM > To: thomas.belling@siemens.com; aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs=20 > requires new A pplication-ID >=20 >=20 > Thomas, >=20 > > Due to concerns about the administrative overhaed I suggested=20 > > decreasing the burden for appication IDs ias a possible solution. >=20 > What would be your model for this? >=20 Specification required alone might be enough. On the other hand AVPs require "experts review, specification = required", and the resulting application ID(s) are likely to be = documented in the same document, so the practical difference may be = small. Vendor specific application IDs on "first come, first served" basis are = already available, and may be sufficient for applications without = widespread usage. In short, giving the issue a second thought I am no longer convinced a = change is required. However, I doubt the administrative burden ia as large as claimed = previously. > [some text cut] >=20 > > This is basically the old argument that there may be many=20 > application IDs. > > However I agree that this scenario may leed to extremly=20 > high numbers. > > It may depend on the application if many disctrete extensions=20 > > are anticipated. This may indeed be a reason for extra=20 > > negotiation mechanisms within applications. >=20 > Right now, there is no standard way to do extended=20 > negotiation. If there > were one, we could could use this to negotiation sub-feature=20 > support. However, > as there is no solution at present to do this. Do you feel=20 > that this feature > is needed? =20 3GPP pre-ageed (final approval to be expected next week) such a = mechanism. They group new AVPs in so-called "feature sets" and = introduce a capabilty negotiation within the application on feature-set = granularity. The new AVP do not use the =B4M=B4bit even if they are = required to be understood, as the capabilty negotiation guarantees = that. The requirement for such extra negotiation mechanisms may depend upon = the application. 3GPP is likely to update specifications due to new = releases and to correct errors and designes for large network where = gradual updates are an issue. Therefore, 3GPP applications may require = such mechanisms more urgently than other ones. >=20 > John >=20 From owner-aaa-wg@merit.edu Fri Sep 3 10:36:57 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02865 for ; Fri, 3 Sep 2004 10:36:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DDAD9133E; Fri, 3 Sep 2004 10:36:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE71B9125D; Fri, 3 Sep 2004 10:36: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 703B191346 for ; Fri, 3 Sep 2004 10:36:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E9F884471; Fri, 3 Sep 2004 10:36:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by segue.merit.edu (Postfix) with ESMTP id BBA7784460 for ; Fri, 3 Sep 2004 10:36:16 -0400 (EDT) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i83EaE5S003953 for ; Fri, 3 Sep 2004 16:36:14 +0200 Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i83Ea4fU002337 for ; Fri, 3 Sep 2004 16:36:14 +0200 Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Sep 2004 16:35:50 +0200 Message-ID: <9A59FBE53A4DD74B9BCD5E44AFB668A92E8BFD@mchh266e.mchh.siemens.de> From: Belling Thomas To: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 3 Sep 2004 16:36:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable (second attempt, my first email seems to be lost in the AAA server) Hi John, answers inline. Thomas > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Friday, September 03, 2004 8:57 AM > To: thomas.belling@siemens.com; aboba@internaut.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs=20 > requires new A pplication-ID >=20 >=20 > Thomas, >=20 > > Due to concerns about the administrative overhaed I suggested=20 > > decreasing the burden for appication IDs ias a possible solution. >=20 > What would be your model for this? >=20 Specification required alone might be enough. On the other hand AVPs require "experts review, specification = required", and the resulting application ID(s) are likely to be = documented in the same document, so the practical difference may be = small. Vendor specific application IDs on "first come, first served" basis are = already available, and may be sufficient for applications without = widespread usage. In short, giving the issue a second thought I am no longer convinced a = change is required. However, I doubt the administrative burden ia as large as claimed = previously. > [some text cut] >=20 > > This is basically the old argument that there may be many=20 > application IDs. > > However I agree that this scenario may leed to extremly=20 > high numbers. > > It may depend on the application if many disctrete extensions=20 > > are anticipated. This may indeed be a reason for extra=20 > > negotiation mechanisms within applications. >=20 > Right now, there is no standard way to do extended=20 > negotiation. If there > were one, we could could use this to negotiation sub-feature=20 > support. However, > as there is no solution at present to do this. Do you feel=20 > that this feature > is needed? =20 3GPP pre-ageed (final approval to be expected next week) such a = mechanism. They group new AVPs in so-called "feature sets" and = introduce a capabilty negotiation within the application on feature-set = granularity. The new AVP do not use the =B4M=B4bit even if they are = required to be understood, as the capabilty negotiation guarantees = that. The requirement for such extra negotiation mechanisms may depend upon = the application. 3GPP is likely to update specifications due to new = releases and to correct errors and designes for large network where = gradual updates are an issue. Therefore, 3GPP applications may require = such mechanisms more urgently than other ones. >=20 > John >=20 From owner-aaa-wg@merit.edu Mon Sep 6 05:23:52 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16770 for ; Mon, 6 Sep 2004 05:23:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9BE391276; Mon, 6 Sep 2004 05:21:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8687B9127F; Mon, 6 Sep 2004 05:21: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 72D3F91276 for ; Mon, 6 Sep 2004 05:19:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 551EC846F7; Mon, 6 Sep 2004 05:19:05 -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 45C7C846C4 for ; Mon, 6 Sep 2004 05:19:04 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i869J2120379 for ; Mon, 6 Sep 2004 12:19:03 +0300 (EET DST) X-Scanned: Mon, 6 Sep 2004 12:15:57 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i869FvjS004716 for ; Mon, 6 Sep 2004 12:15:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00xJuEzP; Mon, 06 Sep 2004 12:15:09 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i869F2Y12451 for ; Mon, 6 Sep 2004 12:15:02 +0300 (EET DST) Received: from nokia.com ([172.21.42.160]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Sep 2004 12:14:57 +0300 Message-ID: <413C2A92.5070002@nokia.com> Date: Mon, 06 Sep 2004 12:14:58 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: review of draft-ietf-aaa-diameter-sip-04.txt References: <412E4B3B.4020007@kolumbus.fi> <4131A655.8020908@nokia.com> <41370DA8.90204@kolumbus.fi> In-Reply-To: <41370DA8.90204@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Sep 2004 09:14:57.0439 (UTC) FILETIME=[FA9FBAF0:01C493F1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jari: Some more discussion inline. Jari Arkko wrote: > Hi Miguel, and thanks for your quick updates! > Some further discussion inline: > > >>"The Diameter SIP application can be used in a SIP environment where an >>interface to a AAA infrastructure is required to authenticate and >>authorize the usage of SIP resources. This application provides a >>limited support for accounting serviers, limited to the Diameter server >>being able to provide the addresses of accounting severs to the >>Diameter client. " > > > I wonder if it would be useful to provide a recommendation of > what AVPs can be carried in an accounting request. Or define > a one or two new ones. So that you could get the basic accounting > information from SIP at least. Say, caller and callee? Or do you > have them already? > Let me see if I understand. Do you want to extend the Diameter SIP application to be able to carry caller, callee and so on, so that the Diameter SIP app. can do accounting? I wonder if there is a need for it. I believe the Diameter CC app and/or the Diameter base can do this work. So I don't think we need to re-invent the wheel. [snap] > >>>Question: Can the Diameter server decide that this particular SIP >>>request does not require authentication? Can I use just the routing >>>aspect of this spec, or do I always need to authenticate too? >> >> >>We never had a requirement to use the routing aspects of this spec, so I >>never thought about this scenario. But I believe it is possible. Section >>5.5 (Session attemp) provides an example of a routing scenario. While >>this scenario is meant to route incoming requests from other users, I >>believe it is applicable for the case you have in mind. > > > Perhaps you could state this somewhere, just in the interest of > having orthogonal functions... > OK, I have added this text at the end of Section 5.5 Locating the recipient of the SIP request (formerly Session attempt): "he scenario described in this section is also applicable in case an outbound SIP server is interested not in authenticating the user, but requires to locate a further SIP server to route the outbound SIP requests. In this case, the outbound SIP server is mapped to SIP server 1 in Figure 5." > >>>Question: Does the download exchange have to happen in a separate >>>roundtrip, or can we do it in parallel with the MAR/MAA? And why do we >>>need a separate message, this does not seem to be the case in other >>>applications such as NASREQ, all authz information is provided in the >>>same return messages? >> >>First of all, let me start indicating that we need to support two >>scenarios (described in Figures 2 and 3). >> >>If we want to avoid one roundtrip less, then we would need to add the >>"please send me the user profile" semantics to MAR/MAA, and I think is >>simpler just to keep those semantics in the existing SAR/SAA. >> >>Another solution would be to use SAR/SAA in steps 13 and 14 of Figure 2, >>but we would be changing the semantics of SAR/SAA and mixing them with >>MAR/MAA. In this figure 2, MAR clearly has the semantics "please >>authenticate/authorize this user with this credentials", whereas SAR >>indicates "This SIP server will be serving this user, and please send me >>the user profile". >> >>I wouldn't like to mix semantics more. > > > I see your point. How does this match with what is being done > in RADIUS. I can see that you might answer "there is no user profile". > However, I suspect vendors will be adding user profile VSAs anyway... So I guess this should be a question addressed to the RADIUS draft. [snap] >>I added the following paragraphs: >> >>This Diameter SIP application allows a Diameter client to use the >>properties of HTTP Digest authentication[RFC2617] by evaluating or >>sending to the Diameter server the credentials supplied by a user. When >>Section 4 of RFC 2617[RFC2617] discusses HTTP Digest authentication, it >>is also applicable to this memo. >> >>This Diameter SIP application also allows a Diameter client to use the >>properties of HTTP Digest authentication using AKA[RFC3310] by >>evaluating or sending to the Diameter server the credentials supplied by >>a user. Section 5 of RFC 3310[RFC3310] is also applicable to this memo. >> >> >>I don't want to create a dependency on AKA v2, because of two reasons: >>first we haven't studied whether we support it straight forward or not. >>Second, this will create a normative dependency... and I am not sure of >>the fate of AKA v2. > > > I see the problem. > > You could use an informative reference -- its not like you are depending > on those references. Just that you carry Digest in your protocol, and > if people want to read on general Digest security issues they should > go to . > > To me the dependency on AKAv2 is a lower priority issue. Therefore, I would like to focuson errors (a few of them reported already). I am willing to add support to AKAv2 if someone assists me to indicate what is actually neeeded, if something is really needed. Issue 27 created: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue27 [snap] Thanks a lot, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Sep 6 05:25:31 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16867 for ; Mon, 6 Sep 2004 05:25:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2AE79122A; Mon, 6 Sep 2004 05:25:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7056A91231; Mon, 6 Sep 2004 05:25: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 1D4629122A for ; Mon, 6 Sep 2004 05:25:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 02E668475C; Mon, 6 Sep 2004 05:25:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 3E29684775 for ; Mon, 6 Sep 2004 05:25:09 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7ED9389870; Mon, 6 Sep 2004 12:24:52 +0300 (EEST) Message-ID: <413C2CB5.8020107@kolumbus.fi> Date: Mon, 06 Sep 2004 12:24:05 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: review of draft-ietf-aaa-diameter-sip-04.txt References: <412E4B3B.4020007@kolumbus.fi> <4131A655.8020908@nokia.com> <41370DA8.90204@kolumbus.fi> <413C2A92.5070002@nokia.com> In-Reply-To: <413C2A92.5070002@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 Miguel Garcia wrote: >> I wonder if it would be useful to provide a recommendation of >> what AVPs can be carried in an accounting request. Or define >> a one or two new ones. So that you could get the basic accounting >> information from SIP at least. Say, caller and callee? Or do you >> have them already? >> > > Let me see if I understand. Do you want to extend the Diameter SIP > application to be able to carry caller, callee and so on, so that the > Diameter SIP app. can do accounting? What I meant was that Diameter SIP would define caller, callee etc AVP which would be carried by Base/CC accounting commands. > I wonder if there is a need for it. I believe the Diameter CC app and/or > the Diameter base can do this work. So I don't think we need to > re-invent the wheel. No commands should be defined, that's clear. But I'm basically asking if the current set of AVPs (base/cc/sip) plus the base/cc accounting commands are sufficient to do SIP accounting over Diameter. Or do we need a "Diameter SIP Accounting AVPs" RFC at some point in time? If we do, how many AVPs would it contain? If its just two, then it might be more economical to add them to Diameter SIP now. >> >> Perhaps you could state this somewhere, just in the interest of >> having orthogonal functions... >> > > OK, I have added this text at the end of Section 5.5 Locating the > recipient of the SIP request (formerly Session attempt): > > "he scenario described in this section is also applicable in case an > outbound SIP server is interested not in authenticating the user, but > requires to locate a further SIP server to route the outbound SIP > requests. In this case, the outbound SIP server is mapped to SIP server > 1 in Figure 5." Ok. >>> Another solution would be to use SAR/SAA in steps 13 and 14 of Figure >>> 2, but we would be changing the semantics of SAR/SAA and mixing them >>> with MAR/MAA. In this figure 2, MAR clearly has the semantics "please >>> authenticate/authorize this user with this credentials", whereas SAR >>> indicates "This SIP server will be serving this user, and please send >>> me the user profile". >>> >>> I wouldn't like to mix semantics more. >> >> >> >> I see your point. How does this match with what is being done >> in RADIUS. I can see that you might answer "there is no user profile". >> However, I suspect vendors will be adding user profile VSAs anyway... > > > So I guess this should be a question addressed to the RADIUS draft. Maybe. But I fear Wolfgang might say the question should be addressed to you :-) What I'd like achieve is that the two RFCs are aligned. >> I see the problem. >> >> You could use an informative reference -- its not like you are depending >> on those references. Just that you carry Digest in your protocol, and >> if people want to read on general Digest security issues they should >> go to . >> >> > > To me the dependency on AKAv2 is a lower priority issue. Therefore, I Fair enough. > would like to focuson errors (a few of them reported already). I am > willing to add support to AKAv2 if someone assists me to indicate what > is actually neeeded, if something is really needed. > > Issue 27 created: > > http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue27 Thanks, I'll see if can get some suggested text to you. --Jari From owner-aaa-wg@merit.edu Mon Sep 6 06:49:13 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21659 for ; Mon, 6 Sep 2004 06:49:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA73691231; Mon, 6 Sep 2004 06:48:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A70309125E; Mon, 6 Sep 2004 06:48:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96BA591231 for ; Mon, 6 Sep 2004 06:48:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 767448472C; Mon, 6 Sep 2004 06:48:57 -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 079C284744 for ; Mon, 6 Sep 2004 06:48:52 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i86Amo119273 for ; Mon, 6 Sep 2004 13:48:50 +0300 (EET DST) X-Scanned: Mon, 6 Sep 2004 13:43:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i86AhB04014142 for ; Mon, 6 Sep 2004 13:43:11 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00abYjLJ; Mon, 06 Sep 2004 13:41:50 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i86AfnS07001 for ; Mon, 6 Sep 2004 13:41:49 +0300 (EET DST) Received: from nokia.com ([172.21.42.160]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Sep 2004 13:40:51 +0300 Message-ID: <413C3EB4.4020503@nokia.com> Date: Mon, 06 Sep 2004 13:40:52 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: review of draft-ietf-aaa-diameter-sip-04.txt References: <412E4B3B.4020007@kolumbus.fi> <4131A655.8020908@nokia.com> <41370DA8.90204@kolumbus.fi> <413C2A92.5070002@nokia.com> <413C2CB5.8020107@kolumbus.fi> In-Reply-To: <413C2CB5.8020107@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Sep 2004 10:40:51.0551 (UTC) FILETIME=[FAB6CEF0:01C493FD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Miguel Garcia wrote: > >>> I wonder if it would be useful to provide a recommendation of >>> what AVPs can be carried in an accounting request. Or define >>> a one or two new ones. So that you could get the basic accounting >>> information from SIP at least. Say, caller and callee? Or do you >>> have them already? >>> >> >> Let me see if I understand. Do you want to extend the Diameter SIP >> application to be able to carry caller, callee and so on, so that the >> Diameter SIP app. can do accounting? > > > What I meant was that Diameter SIP would define caller, > callee etc AVP which would be carried by Base/CC accounting > commands. Ok, clear. > >> I wonder if there is a need for it. I believe the Diameter CC app >> and/or the Diameter base can do this work. So I don't think we need to >> re-invent the wheel. > > > No commands should be defined, that's clear. But I'm basically > asking if the current set of AVPs (base/cc/sip) plus the base/cc > accounting commands are sufficient to do SIP accounting over > Diameter. Or do we need a "Diameter SIP Accounting AVPs" RFC > at some point in time? If we do, how many AVPs would it contain? > If its just two, then it might be more economical to add them > to Diameter SIP now. I did a fast analysis, and this is the result. Diameter base include a User-Name AVP in the ACR/ACA commands. That is obviously not enough to carry all the charging information. A more detailed charging information should, in addition to the User-Name, include: - Caller identity (Any URI: sip, tel, im, pres) - Callee identity (Any URI: sip, tel, im, pres) - SIP method (INVITE, SUBSCRIBE, MESSAGE) - SIP server reporting URI, perhaps including role - Redirected to: other SIP server - Event type (for SUBSCRIBE/NOTIFY/PUBLISH requests) - Call-ID - Charging ID - Timestamp - Information linking to lower layers (e.g., authorized QoS, edge router, access information session, etc.) Having seen this, I don't think it is feasible, at this stage, trying to complete this work when there are not even requirements written. I have the feeling that, if we go in this direcction, we will not be able to produce something useful, since we don't know what the requirements are. I propose that, in the future, someone may write an I-D that defines these AVPs that work in with the Diameter base protocol and the CC application. [snap] > >>>> Another solution would be to use SAR/SAA in steps 13 and 14 of >>>> Figure 2, but we would be changing the semantics of SAR/SAA and >>>> mixing them with MAR/MAA. In this figure 2, MAR clearly has the >>>> semantics "please authenticate/authorize this user with this >>>> credentials", whereas SAR indicates "This SIP server will be serving >>>> this user, and please send me the user profile". >>>> >>>> I wouldn't like to mix semantics more. >>> >>> >>> >>> >>> I see your point. How does this match with what is being done >>> in RADIUS. I can see that you might answer "there is no user profile". >>> However, I suspect vendors will be adding user profile VSAs anyway... >> >> >> >> So I guess this should be a question addressed to the RADIUS draft. > > > Maybe. But I fear Wolfgang might say the question should be > addressed to you :-) What I'd like achieve is that the two > RFCs are aligned. But what do you want me to write? Something like this? "Note that the [draft-sterman] does not support the functionality of downloading the user profile from the server. Note also that [draft-sterman] is much narrower in scope and does not support routing capabilities, and some other functions". To be honest with you, I wouldn't like to write this text. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Sep 6 09:04:20 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02378 for ; Mon, 6 Sep 2004 09:04:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56B759122D; Mon, 6 Sep 2004 09:01:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2056F9127F; Mon, 6 Sep 2004 09:01: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 E3E449122D for ; Mon, 6 Sep 2004 09:01:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4B478471C; Mon, 6 Sep 2004 09:01:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 6F8AE84543 for ; Mon, 6 Sep 2004 09:01:51 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1615789876; Mon, 6 Sep 2004 16:01:50 +0300 (EEST) Message-ID: <413C5F8F.3080506@kolumbus.fi> Date: Mon, 06 Sep 2004 16:01:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: review of draft-ietf-aaa-diameter-sip-04.txt References: <412E4B3B.4020007@kolumbus.fi> <4131A655.8020908@nokia.com> <41370DA8.90204@kolumbus.fi> <413C2A92.5070002@nokia.com> <413C2CB5.8020107@kolumbus.fi> <413C3EB4.4020503@nokia.com> In-Reply-To: <413C3EB4.4020503@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 Hi Miguel, > I did a fast analysis, and this is the result. > > Diameter base include a User-Name AVP in the ACR/ACA commands. That is > obviously not enough to carry all the charging information. A more > detailed charging information should, in addition to the User-Name, > include: > > - Caller identity (Any URI: sip, tel, im, pres) > - Callee identity (Any URI: sip, tel, im, pres) > - SIP method (INVITE, SUBSCRIBE, MESSAGE) > - SIP server reporting URI, perhaps including role > - Redirected to: other SIP server > - Event type (for SUBSCRIBE/NOTIFY/PUBLISH requests) > - Call-ID > - Charging ID > - Timestamp > - Information linking to lower layers (e.g., authorized QoS, edge > router, access information session, etc.) > > > Having seen this, I don't think it is feasible, at this stage, trying to > complete this work when there are not even requirements written. I have > the feeling that, if we go in this direcction, we will not be able to > produce something useful, since we don't know what the requirements are. > > I propose that, in the future, someone may write an I-D that defines > these AVPs that work in with the Diameter base protocol and the CC > application. Ok. Your analysis looks very good, this was exactly what I was looking for, thanks! And yes, I agree with you that defining these is probably too much right now for your document. But hey, at least we have identified a future work item for someone! > But what do you want me to write? Something like this? > > "Note that the [draft-sterman] does not support the functionality of > downloading the user profile from the server. Note also that > [draft-sterman] is much narrower in scope and does not support routing > capabilities, and some other functions". > > To be honest with you, I wouldn't like to write this text. This wasn't exactly what I was looking for. I guess I still somewhat confused about the role of MAR/MAA vs. SAR/SAA, and whether that has something to do with the difference of authentication and authorization or not. IF that is the split, one could perhaps ask if the RFC 3588 Auth-Request-Type could be used to distinguish the two from each other. This would probably work better with RADIUS too, since Auth-Request-Type=AUTHORIZE_AUTHENTICATE would map easier to Access-Request. But I could be missing something very obvious. --Jari From owner-aaa-wg@merit.edu Tue Sep 7 07:53:56 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14965 for ; Tue, 7 Sep 2004 07:53:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58E58912BB; Tue, 7 Sep 2004 07:53:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 160B891217; Tue, 7 Sep 2004 07:53: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 D0206912B9 for ; Tue, 7 Sep 2004 07:53:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B275D8483B; Tue, 7 Sep 2004 07:53:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zctfs063.nortelnetworks.com (h91s128a237n47.user.nortelnetworks.com [47.237.128.91]) by segue.merit.edu (Postfix) with ESMTP id DB2478481F for ; Tue, 7 Sep 2004 07:53:38 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i87BrTb22064 for ; Tue, 7 Sep 2004 13:53:29 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Sep 2004 13:53:26 +0200 Message-ID: <5149A4FBB886D511AF7100508BF93A1807DCC759@znsgy0k4.europe.nortel.com> From: "Javier Gonzalez Gallego" To: aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Tue, 7 Sep 2004 13:53:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C494D1.497FD88C" 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_01C494D1.497FD88C Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Thomas, The actual text in RFC3588 seems to imply your conclusion, but it is = not fully clear. However what seems to be clear to me is the agreement in = the need to correct it. If we look to the mails arounf 19 of August, = there's a number of opinions and emails in agreement with Bernard Adoba's = sentence asking for a correction: > Included in the list of conditions requiring a new Application-ID is: >=20 > " - Adding new AVPs to the command, which have the "M" bit set." >=20 > Given the discussion since the publication of RFC 3588, I now believe = > that the above sentence is in error. A new Application-ID should not = > be required due to addition of AVPs to an application, whether the=20 > mandatory bit is set or not. When and how this correction will be done is what seems to be still = open. At least, that is my recollection of the debate. Javier -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf = Of Belling Thomas Sent: 03 September 2004 13:01 To: 'john.loughney@nokia.com'; lionel.morand@francetelecom.com; aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs = requires new A pplication-ID Hi all There seems to be an understanding in the group that a new application = ID is mandated if a new AVP mith =B4M=B4Flag is added. However, the text in RFC 3556 seems to indicate it is optional: " = Should a new Diameter usage scenario find itself unable to 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: - Adding new AVPs to the command, which have the "M" bit set. " = This seems to be in line with explanatory text for the =B4M`bit, that also = speaks about AVPs without =B4M=B4bits outside applications: " The 'M' Bit, known as the Mandatory bit, indicates whether = support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation = agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs. The 'M' bit MUST be set according to the rules defined for the = AVP containing it. >>> In order to preserve interoperability, a = Diameter implementation MUST be able to exclude from a Diameter message = any Mandatory AVP which is neither defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in which it appears. <<< ... Diameter implementations are required to support all Mandatory AVPs which are allowed by the message's formal syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing the message. " If the understanding within the group is a new application ID for the = AVPs with the =B4M=B4bit is mandatory, (the below interoperability concerns = may justify that), one could improve the wording. Is that something for the errata? Or is it preferable to keep the wording as it is, and grant a certain = degree of freedom fpr application designers in this difficult field? Thomas > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] > On Behalf Of john.loughney@nokia.com > Sent: Friday, September 03, 2004 11:31 AM > To: lionel.morand@francetelecom.com; aaa-wg@merit.edu > Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit=20 > AVPs requires new A pplication-ID >=20 >=20 > Lionel, >=20 > > > Right now, there is no standard way to do extended > > > negotiation. If there were one, we could could use this to=20 > > > negotiation sub-feature support. However, as there is no=20 > > > solution at present to do this. Do you feel that this=20 > > > feature is needed? =20 > > >=20 > >=20 > > From my point of view, the problem of versioning has > appeared due to the > > "unclear" specification of the extensibility mechanism > (i.e. adding new > > AVP with the M-bit set). To avoid the need for a new > application-ID when > > a new feature is added to an existing Diameter application, > a solution > > was to define versions of the same application and to > specify a specific > > version negotiation at the application layer. But this solution was = > > forced by the "new M-bit AVP -> new application-ID" dogma. > >=20 > > If the base protocol specification clarifies that the > addition of new > > M-bit AVPs doesn't require a new application-ID and the > approriate error > > handling for unsupported AVPs (as proposed by Bernard), this will=20 > > deprecate the use of version. >=20 > According to our AD, adding new mandatory AVPs causes = interoperability=20 > problems, therefore the current text remains as is. If we would like = > to modify that behavior, we most likely need to document the new=20 > functionality in an RFC. >=20 > John >=20 ------_=_NextPart_001_01C494D1.497FD88C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires = new A pplication-ID

Thomas,
The actual text in RFC3588 seems to imply your = conclusion, but it is not fully clear. However what seems to be clear = to me is the agreement in the need to correct it. If we look to the = mails arounf 19 of August, there's a number of opinions and  = emails in agreement with Bernard Adoba's sentence asking for a = correction:

> Included in the list of conditions requiring a = new Application-ID is:
>
> "   -  Adding new AVPs to = the command, which have the "M" bit set."
>
> Given the discussion since the publication of = RFC 3588, I now believe
> that the above sentence is in error.  A = new Application-ID should not
> be required due to addition of AVPs to an = application, whether the
> mandatory bit is set or not.


When and how this correction will be done is what = seems to be still open.

At least, that is my recollection of the = debate.
Javier


-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ] On Behalf Of Belling Thomas
Sent: 03 September 2004 13:01
To: 'john.loughney@nokia.com'; = lionel.morand@francetelecom.com; aaa-wg@merit.edu
Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding = 'M' bit AVPs requires new A pplication-ID


Hi all

There seems to be an understanding in the group that = a new application ID is mandated if a new AVP mith =B4M=B4Flag is = added.

However, the text in RFC 3556 seems to indicate it is = optional: " Should a new Diameter usage scenario find itself = unable to 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:

   -  Adding new AVPs to the command, = which have the "M" bit set. " This seems to be in line = with explanatory text for the =B4M`bit, that also speaks about AVPs = without =B4M=B4bits outside applications: "

      The 'M' Bit, known as = the Mandatory bit, indicates whether support
      of the AVP is = required.  If an AVP with the 'M' bit set is
      received by a = Diameter client, server, proxy, or translation agent
      and either the AVP or = its value is unrecognized, the message MUST
      be rejected.  = Diameter Relay and redirect agents MUST NOT reject
      messages with = unrecognized AVPs.

      The 'M' bit MUST be = set according to the rules defined for the AVP
      containing it.  = >>> In order to preserve interoperability, a Diameter
      implementation MUST = be able to exclude from a Diameter message any
      Mandatory AVP which = is neither defined in the base Diameter
      protocol nor in any = of the Diameter Application specifications
      governing the message = in which it appears. <<< ...

      Diameter = implementations are required to support all Mandatory
      AVPs which are = allowed by the message's formal syntax and defined
      either in the base = Diameter standard or in one of the Diameter
      Application = specifications governing the message.
"

If the understanding within the group is a new = application ID for the AVPs with the =B4M=B4bit is mandatory, (the = below interoperability concerns may justify that), one could improve = the wording. Is that something for the errata?

Or is it preferable to keep the wording as it is, and = grant a certain degree of freedom fpr application designers in this = difficult field?


Thomas



> -----Original Message-----
> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu= ]
> On Behalf Of john.loughney@nokia.com
> Sent: Friday, September 03, 2004 11:31 = AM
> To: lionel.morand@francetelecom.com; = aaa-wg@merit.edu
> Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: = Adding 'M' bit
> AVPs requires new A pplication-ID
>
>
> Lionel,
>
> > > Right now, there is no standard way = to do extended
> > > negotiation.  If there were one, = we could could use this to
> > > negotiation sub-feature = support.  However, as there is no
> > > solution at present to do this.  = Do you feel that this
> > > feature is needed? 
> > >
> >
> > From my point of view, the problem of = versioning has
> appeared due to the
> > "unclear" specification of the = extensibility mechanism
> (i.e. adding new
> > AVP with the M-bit set). To avoid the need = for a new
> application-ID when
> > a new feature is added to an existing = Diameter application,
> a solution
> > was to define versions of the same = application and to
> specify a specific
> > version negotiation at the application = layer. But this solution was
> > forced by the "new M-bit AVP -> = new application-ID" dogma.
> >
> > If the base protocol specification = clarifies that the
> addition of new
> > M-bit AVPs doesn't require a new = application-ID and the
> approriate error
> > handling for unsupported AVPs (as proposed = by Bernard), this will
> > deprecate the use of version.
>
> According to our AD, adding new mandatory AVPs = causes interoperability
> problems, therefore the current text remains as = is.  If we would like
> to modify that behavior, we most likely need to = document the new
> functionality in an RFC.
>
> John
>

------_=_NextPart_001_01C494D1.497FD88C-- From owner-aaa-wg@merit.edu Tue Sep 7 20:03:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19745 for ; Tue, 7 Sep 2004 20:03:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 555C791249; Tue, 7 Sep 2004 20:03:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CCAF9123D; Tue, 7 Sep 2004 20:03: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 87B8891249 for ; Tue, 7 Sep 2004 20:02:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6645484504; Tue, 7 Sep 2004 20:02:58 -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 5AA2B844DF for ; Tue, 7 Sep 2004 20:02:57 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8802uj26170; Wed, 8 Sep 2004 03:02:56 +0300 (EET DST) X-Scanned: Wed, 8 Sep 2004 03:01:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i8801pE9001083; Wed, 8 Sep 2004 03:01:51 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00D4cRQc; Wed, 08 Sep 2004 03:01:50 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8801iY00229; Wed, 8 Sep 2004 03:01:44 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Sep 2004 03:01:42 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Sep 2004 03:01:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49537.04981F98" Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Wed, 8 Sep 2004 03:01:40 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D08926F@esebe056.ntc.nokia.com> Thread-Topic: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSU0iMgQEKhBaMYRti4F7jcVBKNSwAZKmWg From: To: , X-OriginalArrivalTime: 08 Sep 2004 00:01:41.0967 (UTC) FILETIME=[05682DF0:01C49537] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C49537.04981F98 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Javier, =20 Our AD has stated that we can make a simple erratta to RFC 3588 to make = this change. So at present, this is not an option on that is on the table. If we would = like to change the RFC, then we will need to produce a new RFC. =20 John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Javier Gonzalez Gallego Sent: 07 September, 2004 14:53 To: aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs = requires new A pplication-ID Thomas,=20 The actual text in RFC3588 seems to imply your conclusion, but it is not = fully clear. However what seems to be clear to me is the agreement in = the need to correct it. If we look to the mails arounf 19 of August, = there's a number of opinions and emails in agreement with Bernard = Adoba's sentence asking for a correction: > Included in the list of conditions requiring a new Application-ID is:=20 >=20 > " - Adding new AVPs to the command, which have the "M" bit set."=20 >=20 > Given the discussion since the publication of RFC 3588, I now believe=20 > that the above sentence is in error. A new Application-ID should not=20 > be required due to addition of AVPs to an application, whether the=20 > mandatory bit is set or not.=20 When and how this correction will be done is what seems to be still = open.=20 At least, that is my recollection of the debate.=20 Javier=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu] On Behalf = Of Belling Thomas=20 Sent: 03 September 2004 13:01=20 To: 'john.loughney@nokia.com'; lionel.morand@francetelecom.com; = aaa-wg@merit.edu=20 Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs = requires new A pplication-ID=20 Hi all=20 There seems to be an understanding in the group that a new application = ID is mandated if a new AVP mith =B4M=B4Flag is added. However, the text in RFC 3556 seems to indicate it is optional: " Should = a new Diameter usage scenario find itself unable to fit within an existing application without requiring major changes to the=20 specification, it may be desirable to create a new Diameter=20 application. Major changes to an application include:=20 - Adding new AVPs to the command, which have the "M" bit set. " This = seems to be in line with explanatory text for the =B4M`bit, that also = speaks about AVPs without =B4M=B4bits outside applications: " The 'M' Bit, known as the Mandatory bit, indicates whether support = of the AVP is required. If an AVP with the 'M' bit set is=20 received by a Diameter client, server, proxy, or translation agent = and either the AVP or its value is unrecognized, the message MUST=20 be rejected. Diameter Relay and redirect agents MUST NOT reject=20 messages with unrecognized AVPs.=20 The 'M' bit MUST be set according to the rules defined for the AVP = containing it. >>> In order to preserve interoperability, a = Diameter=20 implementation MUST be able to exclude from a Diameter message any = Mandatory AVP which is neither defined in the base Diameter=20 protocol nor in any of the Diameter Application specifications=20 governing the message in which it appears. <<< ...=20 Diameter implementations are required to support all Mandatory=20 AVPs which are allowed by the message's formal syntax and defined=20 either in the base Diameter standard or in one of the Diameter=20 Application specifications governing the message.=20 "=20 If the understanding within the group is a new application ID for the = AVPs with the =B4M=B4bit is mandatory, (the below interoperability = concerns may justify that), one could improve the wording. Is that = something for the errata? Or is it preferable to keep the wording as it is, and grant a certain = degree of freedom fpr application designers in this difficult field? Thomas=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu]=20 > On Behalf Of john.loughney@nokia.com=20 > Sent: Friday, September 03, 2004 11:31 AM=20 > To: lionel.morand@francetelecom.com; aaa-wg@merit.edu=20 > Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit=20 > AVPs requires new A pplication-ID=20 >=20 >=20 > Lionel,=20 >=20 > > > Right now, there is no standard way to do extended=20 > > > negotiation. If there were one, we could could use this to=20 > > > negotiation sub-feature support. However, as there is no=20 > > > solution at present to do this. Do you feel that this=20 > > > feature is needed? =20 > > >=20 > >=20 > > From my point of view, the problem of versioning has=20 > appeared due to the=20 > > "unclear" specification of the extensibility mechanism=20 > (i.e. adding new=20 > > AVP with the M-bit set). To avoid the need for a new=20 > application-ID when=20 > > a new feature is added to an existing Diameter application,=20 > a solution=20 > > was to define versions of the same application and to=20 > specify a specific=20 > > version negotiation at the application layer. But this solution was=20 > > forced by the "new M-bit AVP -> new application-ID" dogma.=20 > >=20 > > If the base protocol specification clarifies that the=20 > addition of new=20 > > M-bit AVPs doesn't require a new application-ID and the=20 > approriate error=20 > > handling for unsupported AVPs (as proposed by Bernard), this will=20 > > deprecate the use of version.=20 >=20 > According to our AD, adding new mandatory AVPs causes interoperability = > problems, therefore the current text remains as is. If we would like=20 > to modify that behavior, we most likely need to document the new=20 > functionality in an RFC.=20 >=20 > John=20 >=20 ------_=_NextPart_001_01C49537.04981F98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires = new A pplication-ID
Javier,
 
Our AD=20 has stated that we can make a simple erratta to RFC 3588 to make this=20 change.  So at
present, this is not an option on that is on the table.  = If we would=20 like to change the RFC,
then=20 we will need to produce a new RFC.
 
John
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Javier Gonzalez = Gallego
Sent: 07 September, 2004 14:53
To:=20 aaa-wg@merit.edu
Subject: RE: RE : [AAA-WG]: RFC 3588 = Errata: Adding=20 'M' bit AVPs requires new A pplication-ID

Thomas,
The actual text in = RFC3588=20 seems to imply your conclusion, but it is not fully clear. However = what seems=20 to be clear to me is the agreement in the need to correct it. If we = look to=20 the mails arounf 19 of August, there's a number of opinions and  = emails=20 in agreement with Bernard Adoba's sentence asking for a = correction:

> Included in the list of conditions requiring a = new=20 Application-ID is:
>
>=20 "   -  Adding new AVPs to the command, which have the = "M" bit=20 set."
>
> = Given the=20 discussion since the publication of RFC 3588, I now believe =
> that the above sentence is in error.  A new = Application-ID=20 should not
> be required due to addition = of AVPs to=20 an application, whether the
> mandatory = bit is set=20 or not.


When and how this correction will be done is what = seems to be=20 still open.

At least, that is my recollection of the = debate.=20
Javier


-----Original Message-----
From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of Belling Thomas
Sent: 03 September = 2004=20 13:01
To: 'john.loughney@nokia.com';=20 lionel.morand@francetelecom.com; aaa-wg@merit.edu
Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit = AVPs=20 requires new A pplication-ID


Hi all

There seems to be an understanding in the group that = a new=20 application ID is mandated if a new AVP mith =B4M=B4Flag is = added.

However, the text in RFC 3556 seems to indicate it = is=20 optional: " Should a new Diameter usage scenario find itself unable to = fit=20 within

   an existing application without = requiring major=20 changes to the
   specification, = it may be=20 desirable to create a new Diameter
  =20 application.  Major changes to an application include: =

   -  Adding new AVPs to the command, = which=20 have the "M" bit set. " This seems to be in line with explanatory text = for the=20 =B4M`bit, that also speaks about AVPs without =B4M=B4bits outside = applications:=20 "

      The 'M' Bit, known as = the=20 Mandatory bit, indicates whether support
      of the AVP is required.  = If an AVP=20 with the 'M' bit set is
     =20 received by a Diameter client, server, proxy, or translation = agent=20
      and either the AVP = or its=20 value is unrecognized, the message MUST
      be rejected.  Diameter = Relay and=20 redirect agents MUST NOT reject
      messages with unrecognized = AVPs.=20

      The 'M' bit MUST be = set=20 according to the rules defined for the AVP
      containing it.  = >>> In=20 order to preserve interoperability, a Diameter
      implementation MUST be able to = exclude=20 from a Diameter message any
      Mandatory AVP which is neither = defined=20 in the base Diameter
     =20 protocol nor in any of the Diameter Application specifications=20
      governing the = message in which=20 it appears. <<< ...

      Diameter = implementations are=20 required to support all Mandatory
      AVPs which are allowed by the = message's=20 formal syntax and defined
      either in the base Diameter = standard or=20 in one of the Diameter
     =20 Application specifications governing the message.
"

If the understanding within the group is a new = application ID=20 for the AVPs with the =B4M=B4bit is mandatory, (the below = interoperability=20 concerns may justify that), one could improve the wording. Is that = something=20 for the errata?

Or is it preferable to keep the wording as it is, = and grant a=20 certain degree of freedom fpr application designers in this difficult=20 field?


Thomas



> -----Original Message-----
>=20 From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= =20
> On Behalf Of john.loughney@nokia.com =
> Sent: Friday, September 03, 2004 11:31 AM =
> To: lionel.morand@francetelecom.com; = aaa-wg@merit.edu=20
> Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: = Adding 'M'=20 bit
> AVPs requires new A = pplication-ID=20
>
> =
> Lionel,
>
>=20 > > Right now, there is no standard way to do extended =
> > > negotiation.  If there were one, we could = could use=20 this to
> > > negotiation = sub-feature=20 support.  However, as there is no
> = > >=20 solution at present to do this.  Do you feel that this =
> > > feature is needed? 
>=20 > >
> >
> >=20 From my point of view, the problem of versioning has
> appeared due to the
> > = "unclear"=20 specification of the extensibility mechanism
>=20 (i.e. adding new
> > AVP with the = M-bit set). To=20 avoid the need for a new
> application-ID = when
> > a new feature is added to an = existing=20 Diameter application,
> a solution =
> > was to define versions of the same application and = to=20
> specify a specific
> >=20 version negotiation at the application layer. But this solution was=20
> > forced by the "new M-bit AVP -> = new=20 application-ID" dogma.
> > =
> > If the base protocol specification clarifies that = the=20
> addition of new
> = > M-bit=20 AVPs doesn't require a new application-ID and the
>=20 approriate error
> > handling for = unsupported=20 AVPs (as proposed by Bernard), this will
> >=20 deprecate the use of version.
> =
> According to our AD, adding new mandatory AVPs causes=20 interoperability
> problems, therefore = the current=20 text remains as is.  If we would like
> to=20 modify that behavior, we most likely need to document the new =
> functionality in an RFC.
>=20
> John
>=20

------_=_NextPart_001_01C49537.04981F98-- From owner-aaa-wg@merit.edu Tue Sep 7 20:20:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20770 for ; Tue, 7 Sep 2004 20:20:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 527EC9124B; Tue, 7 Sep 2004 20:19:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DFB49123D; Tue, 7 Sep 2004 20:19: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 136519124D for ; Tue, 7 Sep 2004 20:19:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDFD1845FD; Tue, 7 Sep 2004 20:19:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id A66AA8464B for ; Tue, 7 Sep 2004 20:19:40 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i880Bcx22769; Tue, 7 Sep 2004 17:11:38 -0700 Date: Tue, 7 Sep 2004 17:11:38 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: ggfj@nortelnetworks.com, aaa-wg@merit.edu Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D08926F@esebe056.ntc.nokia.com> Message-ID: References: <3CF661B1787ABF41A869BE20108F8D6D08926F@esebe056.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > If we would like to change the RFC, then we will need to produce a new > RFC. Producing an RFC is not by itself an obstacle, assuming: a. We have consensus that there is a problem with the current text of RFC 3588. That is, that there are situations in which it will be desirable to add support for *IETF Standard* AVPs with the 'M' bit set, without having to create a new *IETF Standard* Application-ID. This argument in turn rests on the need to add support for small numbers of additional IETF Standard AVPs, rather than aggregating support for a set of AVPs into a new Application. As Barney Wolff argued, there may be good reasons for aggregation, aside from the RFC 3588 issues. For example, there is a question about whether it even makes sense to support additional attributes in RADIUS in granularities smaller than a "feature". b. We have consensus that addition of *Vendor Specific* AVPs with the 'M' bit set still requires a new Application-ID. Here again the issues arises as to whether support for multiple VSAs should require allocation of multiple Vendor-Specific Application-IDs, or just one. c. We have consensus that other changes described in RFC 3588 (such as new command codes, changes in the round trips, etc.) still require a new Application-ID. From owner-aaa-wg@merit.edu Wed Sep 8 02:59:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15054 for ; Wed, 8 Sep 2004 02:59:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5BBA69124E; Wed, 8 Sep 2004 02:59:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2703A91252; Wed, 8 Sep 2004 02:59: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 151419124E for ; Wed, 8 Sep 2004 02:59:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDF3B846A5; Wed, 8 Sep 2004 02:59:15 -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 10D0784563 for ; Wed, 8 Sep 2004 02:59:15 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i886xB119887; Wed, 8 Sep 2004 09:59:11 +0300 (EET DST) X-Scanned: Wed, 8 Sep 2004 09:54:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i886snKg013989; Wed, 8 Sep 2004 09:54:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00kW1XSc; Wed, 08 Sep 2004 09:54:47 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i886siY27105; Wed, 8 Sep 2004 09:54:44 +0300 (EET DST) Received: from nokia.com ([172.21.42.160]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Sep 2004 09:54:28 +0300 Message-ID: <413EACA4.8020808@nokia.com> Date: Wed, 08 Sep 2004 09:54:28 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Bernard Aboba Cc: john.loughney@nokia.com, ggfj@nortelnetworks.com, aaa-wg@merit.edu Subject: Re: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID References: <3CF661B1787ABF41A869BE20108F8D6D08926F@esebe056.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2004 06:54:28.0574 (UTC) FILETIME=[AF747FE0:01C49570] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I just want to point out that, if the WG decides to update RFC 3588, it may be a good idea to import the text of the AAA URI draft: http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt The motivation: this draft proposes an update to the AAA URI scheme. This text should have been in RFC 3588. Regards, Miguel Bernard Aboba wrote: >>If we would like to change the RFC, then we will need to produce a new >>RFC. > > > Producing an RFC is not by itself an obstacle, assuming: > > a. We have consensus that there is a problem with the current text of RFC > 3588. That is, that there are situations in which it will be > desirable to add support for *IETF Standard* AVPs with the 'M' bit set, > without having to create a new *IETF Standard* Application-ID. This > argument in turn rests on the need to add support for small numbers > of additional IETF Standard AVPs, rather than aggregating support for > a set of AVPs into a new Application. As Barney Wolff argued, there > may be good reasons for aggregation, aside from the RFC 3588 issues. > For example, there is a question about whether it even makes sense > to support additional attributes in RADIUS in granularities smaller > than a "feature". > > b. We have consensus that addition of *Vendor Specific* AVPs with the > 'M' bit set still requires a new Application-ID. Here again the > issues arises as to whether support for multiple VSAs should require > allocation of multiple Vendor-Specific Application-IDs, or just > one. > > c. We have consensus that other changes described in RFC 3588 (such as new > command codes, changes in the round trips, etc.) still require a new > Application-ID. > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Wed Sep 8 11:53:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23316 for ; Wed, 8 Sep 2004 11:53:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF53C912FF; Wed, 8 Sep 2004 11:50:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E93F912FD; Wed, 8 Sep 2004 11:50: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 4FB15912E0 for ; Wed, 8 Sep 2004 11:50:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D7B584681; Wed, 8 Sep 2004 11:50:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id B26BB8467C for ; Wed, 8 Sep 2004 11:50:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i88Fe3l11664; Wed, 8 Sep 2004 08:40:04 -0700 Date: Wed, 8 Sep 2004 08:40:03 -0700 (PDT) From: Bernard Aboba To: Miguel Garcia Cc: john.loughney@nokia.com, ggfj@nortelnetworks.com, aaa-wg@merit.edu Subject: Re: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new Application-ID In-Reply-To: <413EACA4.8020808@nokia.com> Message-ID: References: <3CF661B1787ABF41A869BE20108F8D6D08926F@esebe056.ntc.nokia.com> <413EACA4.8020808@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I just want to point out that, if the WG decides to update RFC 3588, it > may be a good idea to import the text of the AAA URI draft: To my knowledge, there has been no discussion about issuing an RFC 3588bis document so far. From owner-aaa-wg@merit.edu Thu Sep 9 20:18:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19103 for ; Thu, 9 Sep 2004 20:18:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 525C69130B; Thu, 9 Sep 2004 20:18:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E95B69130D; Thu, 9 Sep 2004 20:18: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 88D4A9130B for ; Thu, 9 Sep 2004 20:18:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B52D84653; Thu, 9 Sep 2004 20:18:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from dingo.dogpad.net (dingo.dogpad.net [65.70.180.33]) by segue.merit.edu (Postfix) with ESMTP id 23F1C8460A for ; Thu, 9 Sep 2004 20:18:16 -0400 (EDT) Received: from dogpad.net (localhost [127.0.0.1]) by dingo.dogpad.net (Postfix) with ESMTP id BEF6135136; Thu, 9 Sep 2004 19:17:55 -0500 (CDT) Message-ID: <4140F2B3.2080204@dogpad.net> Date: Thu, 09 Sep 2004 19:17:55 -0500 From: Joseph Harvell Reply-To: harvell@nortelnetworks.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: harvell@nortelnetworks.com Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit DCC draft 6 proposes AVP Code value 458 for both User-Equipment-Info and Service-Context-Id AVPs. I am implementing the encoding of Service-Context-Id. Does someone have an idea which AVP code will likely be assigned for Service-Context-Id? From owner-aaa-wg@merit.edu Thu Sep 9 20:30:44 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19767 for ; Thu, 9 Sep 2004 20:30:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7499391211; Thu, 9 Sep 2004 20:30:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1DBC9130D; Thu, 9 Sep 2004 20:30: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 5508491211 for ; Thu, 9 Sep 2004 20:30:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3F2A844C8; Thu, 9 Sep 2004 20:30:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from dingo.dogpad.net (dingo.dogpad.net [65.70.180.33]) by segue.merit.edu (Postfix) with ESMTP id E09348481D for ; Thu, 9 Sep 2004 20:30:03 -0400 (EDT) Received: from dogpad.net (localhost [127.0.0.1]) by dingo.dogpad.net (Postfix) with ESMTP id 2503835332; Thu, 9 Sep 2004 19:29:40 -0500 (CDT) Message-ID: <4140F573.2060604@dogpad.net> Date: Thu, 09 Sep 2004 19:29:39 -0500 From: Joseph Harvell Reply-To: harvell@nortelnetworks.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: harvell@nortelnetworks.com Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict 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 DCC draft 6 proposes AVP Code value 458 for both User-Equipment-Info and Service-Context-Id AVPs. I am implementing the encoding of Service-Context-Id. Does someone have an idea which AVP code will likely be assigned for Service-Context-Id? From owner-aaa-wg@merit.edu Fri Sep 10 07:36:02 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16161 for ; Fri, 10 Sep 2004 07:36:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BC86D9121B; Fri, 10 Sep 2004 07:35:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 924DF91324; Fri, 10 Sep 2004 07:35: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 61BE19121B for ; Fri, 10 Sep 2004 07:35:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E0E18487A; Fri, 10 Sep 2004 07:35:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hlmail01.vfl.vodafone (mailgate1.vodafone.co.uk [194.62.232.133]) by segue.merit.edu (Postfix) with ESMTP id 73DB38484A for ; Fri, 10 Sep 2004 07:35:48 -0400 (EDT) Received: from ukwcs01.vf-uk.internal.vodafone.com (ukwcs01 [10.33.127.9]) by hlmail01.vfl.vodafone (8.11.6/8.11.6) with ESMTP id i8ABZlO25026; Fri, 10 Sep 2004 12:35:47 +0100 Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by ukwcs01.vf-uk.internal.vodafone.com (4.9.7.3) with ESMTP id DO91cAAX; Fri, 10 Sep 2004 12:35:49 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Fri, 10 Sep 2004 12:35:36 +0100 Received: from ukwmxm11.vf-uk.internal.vodafone.com ([10.33.113.32]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Fri, 10 Sep 2004 12:35:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 10 Sep 2004 12:35:40 +0100 Message-ID: Thread-Topic: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSRw5SNsPwWl222QSuKo9m0lvChygFZLKSA From: "Warren, Dan, VF UK - Technology (TS)" To: "Belling Thomas" , X-OriginalArrivalTime: 10 Sep 2004 11:35:51.0241 (UTC) FILETIME=[53228B90:01C4972A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Thomas Belling wrote;- '3GPP pre-ageed (final approval to be expected next week) such a = mechanism. They group new AVPs in so-called "feature sets" and introduce = a capabilty negotiation within the application on feature-set = granularity. The new AVP do not use the =B4M=B4bit even if they are = required to be understood, as the capabilty negotiation guarantees that. The requirement for such extra negotiation mechanisms may depend upon = the application. 3GPP is likely to update specifications due to new = releases and to correct errors and designes for large network where = gradual updates are an issue. Therefore, 3GPP applications may require = such mechanisms more urgently than other ones.' Accompanying the proposal in 3GPP is a considerable set of guidleines on = what constitutes a 'feature' and what would motivate the creation of a = new application-id. This has led to the definition of some working = practises on how AVPs, features and applications are created and how = forward compatibility within (3GPP defined) Diameter applications can be = achieved. If/when it is decided to introduce a similar mechanism for = identification of features in IETF, it might be useful to have a some = similar guidance about what is a feature and what warrants a new = application. When that time comes, I'm sure one of the 3GPP-ists on the = list will be happy to provide the text. Cheers Dan Warren From owner-aaa-wg@merit.edu Fri Sep 10 09:54:28 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26608 for ; Fri, 10 Sep 2004 09:54:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0253091324; Fri, 10 Sep 2004 09:54:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B95389132E; Fri, 10 Sep 2004 09:54: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 A253091324 for ; Fri, 10 Sep 2004 09:54:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F8C6848AA; Fri, 10 Sep 2004 09:54:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 44E43848AB for ; Fri, 10 Sep 2004 09:54:12 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i8ADs9a9029299 for ; Fri, 10 Sep 2004 08:54:10 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Sep 2004 15:54:08 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550526BC3A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: john.loughney@nokia.com, ggfj@nortelnetworks.com, aaa-wg@merit.edu Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requi res new A pplication-ID Date: Fri, 10 Sep 2004 15:54:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4973D.A3A88F8E" 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_01C4973D.A3A88F8E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, September 08, 2004 02:02 To: ggfj@nortelnetworks.com; aaa-wg@merit.edu Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs = requires new A pplication-ID Javier, =20 Our AD has stated that we can make a simple erratta to RFC 3588 to make = this change. So at=20 =20 I think you meant "can NOT make" !!?? =20 present, this is not an option on that is on the table. If we would = like to change the RFC, then we will need to produce a new RFC. =20 John -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf = Of ext Javier Gonzalez Gallego Sent: 07 September, 2004 14:53 To: aaa-wg@merit.edu Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs = requires new A pplication-ID Thomas,=20 The actual text in RFC3588 seems to imply your conclusion, but it is = not fully clear. However what seems to be clear to me is the agreement = in the need to correct it. If we look to the mails arounf 19 of August, = there's a number of opinions and emails in agreement with Bernard = Adoba's sentence asking for a correction: > Included in the list of conditions requiring a new Application-ID is: = >=20 > " - Adding new AVPs to the command, which have the "M" bit set."=20 >=20 > Given the discussion since the publication of RFC 3588, I now believe = > that the above sentence is in error. A new Application-ID should not = > be required due to addition of AVPs to an application, whether the=20 > mandatory bit is set or not.=20 When and how this correction will be done is what seems to be still = open.=20 At least, that is my recollection of the debate.=20 Javier=20 -----Original Message-----=20 From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu = ] On Behalf Of Belling Thomas=20 Sent: 03 September 2004 13:01=20 To: 'john.loughney@nokia.com'; lionel.morand@francetelecom.com; = aaa-wg@merit.edu=20 Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs = requires new A pplication-ID=20 Hi all=20 There seems to be an understanding in the group that a new application = ID is mandated if a new AVP mith =B4M=B4Flag is added. However, the text in RFC 3556 seems to indicate it is optional: " = Should a new Diameter usage scenario find itself unable to fit within an existing application without requiring major changes to the=20 specification, it may be desirable to create a new Diameter=20 application. Major changes to an application include:=20 - Adding new AVPs to the command, which have the "M" bit set. " = This seems to be in line with explanatory text for the =B4M`bit, that = also speaks about AVPs without =B4M=B4bits outside applications: " The 'M' Bit, known as the Mandatory bit, indicates whether = support=20 of the AVP is required. If an AVP with the 'M' bit set is=20 received by a Diameter client, server, proxy, or translation = agent=20 and either the AVP or its value is unrecognized, the message MUST = be rejected. Diameter Relay and redirect agents MUST NOT reject=20 messages with unrecognized AVPs.=20 The 'M' bit MUST be set according to the rules defined for the = AVP=20 containing it. >>> In order to preserve interoperability, a = Diameter=20 implementation MUST be able to exclude from a Diameter message = any=20 Mandatory AVP which is neither defined in the base Diameter=20 protocol nor in any of the Diameter Application specifications=20 governing the message in which it appears. <<< ...=20 Diameter implementations are required to support all Mandatory=20 AVPs which are allowed by the message's formal syntax and defined = either in the base Diameter standard or in one of the Diameter=20 Application specifications governing the message.=20 "=20 If the understanding within the group is a new application ID for the = AVPs with the =B4M=B4bit is mandatory, (the below interoperability = concerns may justify that), one could improve the wording. Is that = something for the errata? Or is it preferable to keep the wording as it is, and grant a certain = degree of freedom fpr application designers in this difficult field? Thomas=20 > -----Original Message-----=20 > From: owner-aaa-wg@merit.edu [ mailto:owner-aaa-wg@merit.edu = ]=20 > On Behalf Of john.loughney@nokia.com=20 > Sent: Friday, September 03, 2004 11:31 AM=20 > To: lionel.morand@francetelecom.com; aaa-wg@merit.edu=20 > Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit=20 > AVPs requires new A pplication-ID=20 >=20 >=20 > Lionel,=20 >=20 > > > Right now, there is no standard way to do extended=20 > > > negotiation. If there were one, we could could use this to=20 > > > negotiation sub-feature support. However, as there is no=20 > > > solution at present to do this. Do you feel that this=20 > > > feature is needed? =20 > > >=20 > >=20 > > From my point of view, the problem of versioning has=20 > appeared due to the=20 > > "unclear" specification of the extensibility mechanism=20 > (i.e. adding new=20 > > AVP with the M-bit set). To avoid the need for a new=20 > application-ID when=20 > > a new feature is added to an existing Diameter application,=20 > a solution=20 > > was to define versions of the same application and to=20 > specify a specific=20 > > version negotiation at the application layer. But this solution was = > > forced by the "new M-bit AVP -> new application-ID" dogma.=20 > >=20 > > If the base protocol specification clarifies that the=20 > addition of new=20 > > M-bit AVPs doesn't require a new application-ID and the=20 > approriate error=20 > > handling for unsupported AVPs (as proposed by Bernard), this will=20 > > deprecate the use of version.=20 >=20 > According to our AD, adding new mandatory AVPs causes = interoperability=20 > problems, therefore the current text remains as is. If we would like = > to modify that behavior, we most likely need to document the new=20 > functionality in an RFC.=20 >=20 > John=20 >=20 ------_=_NextPart_001_01C4973D.A3A88F8E Content-Type: text/html; charset="iso-8859-1" RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID
 
-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Wednesday, September 08, 2004 02:02
To: ggfj@nortelnetworks.com; aaa-wg@merit.edu
Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID

Javier,
 
Our AD has stated that we can make a simple erratta to RFC 3588 to make this change.  So at 
 
<bert> I think you meant "can NOT make" !!??
<bert>
 
present, this is not an option on that is on the table.  If we would like to change the RFC,
then we will need to produce a new RFC.
 
John
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Javier Gonzalez Gallego
Sent: 07 September, 2004 14:53
To: aaa-wg@merit.edu
Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID

Thomas,
The actual text in RFC3588 seems to imply your conclusion, but it is not fully clear. However what seems to be clear to me is the agreement in the need to correct it. If we look to the mails arounf 19 of August, there's a number of opinions and  emails in agreement with Bernard Adoba's sentence asking for a correction:

> Included in the list of conditions requiring a new Application-ID is:
>
> "   -  Adding new AVPs to the command, which have the "M" bit set."
>
> Given the discussion since the publication of RFC 3588, I now believe
> that the above sentence is in error.  A new Application-ID should not
> be required due to addition of AVPs to an application, whether the
> mandatory bit is set or not.


When and how this correction will be done is what seems to be still open.

At least, that is my recollection of the debate.
Javier


-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Belling Thomas
Sent: 03 September 2004 13:01
To: 'john.loughney@nokia.com'; lionel.morand@francetelecom.com; aaa-wg@merit.edu
Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID


Hi all

There seems to be an understanding in the group that a new application ID is mandated if a new AVP mith īMīFlag is added.

However, the text in RFC 3556 seems to indicate it is optional: " Should a new Diameter usage scenario find itself unable to 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:

   -  Adding new AVPs to the command, which have the "M" bit set. " This seems to be in line with explanatory text for the īM`bit, that also speaks about AVPs without īMībits outside applications: "

      The 'M' Bit, known as the Mandatory bit, indicates whether support
      of the AVP is required.  If an AVP with the 'M' bit set is
      received by a Diameter client, server, proxy, or translation agent
      and either the AVP or its value is unrecognized, the message MUST
      be rejected.  Diameter Relay and redirect agents MUST NOT reject
      messages with unrecognized AVPs.

      The 'M' bit MUST be set according to the rules defined for the AVP
      containing it.  >>> In order to preserve interoperability, a Diameter
      implementation MUST be able to exclude from a Diameter message any
      Mandatory AVP which is neither defined in the base Diameter
      protocol nor in any of the Diameter Application specifications
      governing the message in which it appears. <<< ...

      Diameter implementations are required to support all Mandatory
      AVPs which are allowed by the message's formal syntax and defined
      either in the base Diameter standard or in one of the Diameter
      Application specifications governing the message.
"

If the understanding within the group is a new application ID for the AVPs with the īMībit is mandatory, (the below interoperability concerns may justify that), one could improve the wording. Is that something for the errata?

Or is it preferable to keep the wording as it is, and grant a certain degree of freedom fpr application designers in this difficult field?


Thomas



> -----Original Message-----
> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]
> On Behalf Of john.loughney@nokia.com
> Sent: Friday, September 03, 2004 11:31 AM
> To: lionel.morand@francetelecom.com; aaa-wg@merit.edu
> Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit
> AVPs requires new A pplication-ID
>
>
> Lionel,
>
> > > Right now, there is no standard way to do extended
> > > negotiation.  If there were one, we could could use this to
> > > negotiation sub-feature support.  However, as there is no
> > > solution at present to do this.  Do you feel that this
> > > feature is needed? 
> > >
> >
> > From my point of view, the problem of versioning has
> appeared due to the
> > "unclear" specification of the extensibility mechanism
> (i.e. adding new
> > AVP with the M-bit set). To avoid the need for a new
> application-ID when
> > a new feature is added to an existing Diameter application,
> a solution
> > was to define versions of the same application and to
> specify a specific
> > version negotiation at the application layer. But this solution was
> > forced by the "new M-bit AVP -> new application-ID" dogma.
> >
> > If the base protocol specification clarifies that the
> addition of new
> > M-bit AVPs doesn't require a new application-ID and the
> approriate error
> > handling for unsupported AVPs (as proposed by Bernard), this will
> > deprecate the use of version.
>
> According to our AD, adding new mandatory AVPs causes interoperability
> problems, therefore the current text remains as is.  If we would like
> to modify that behavior, we most likely need to document the new
> functionality in an RFC.
>
> John
>

------_=_NextPart_001_01C4973D.A3A88F8E-- From owner-aaa-wg@merit.edu Fri Sep 10 10:24:14 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00337 for ; Fri, 10 Sep 2004 10:24:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C9549132E; Fri, 10 Sep 2004 10:24:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF81B91332; Fri, 10 Sep 2004 10:24: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 A32F49132E for ; Fri, 10 Sep 2004 10:24:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9124D846D7; Fri, 10 Sep 2004 10:24:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 59E1F8486F for ; Fri, 10 Sep 2004 10:24:00 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8AENtT27186; Fri, 10 Sep 2004 17:23:55 +0300 (EET DST) X-Scanned: Fri, 10 Sep 2004 17:21:42 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8AELgqv029759; Fri, 10 Sep 2004 17:21:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Yf4KJG; Fri, 10 Sep 2004 17:21:40 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8AE3gY08572; Fri, 10 Sep 2004 17:03:42 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 17:02:17 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 10 Sep 2004 17:02:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Date: Fri, 10 Sep 2004 17:02:17 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D0892A6@esebe056.ntc.nokia.com> Thread-Topic: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID Thread-Index: AcSXPfjvCQ0bhFczTZeTAS8gH3JvJQAAK5Xg From: To: , , X-OriginalArrivalTime: 10 Sep 2004 14:02:17.0758 (UTC) FILETIME=[C84EA3E0:01C4973E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Bert, > Javier, >=20 > Our AD has stated that we can make a simple erratta to RFC 3588 to = make this change. So at=20 > > I think you meant "can NOT make" !!?? > >=20 > present, this is not an option on that is on the table. If we would = like to change the RFC, > then we will need to produce a new RFC. You are correct, I meant: Our AD has stated that we can not make a simple erratta to RFC 3588 to = make this change. =20 John From owner-aaa-wg@merit.edu Fri Sep 10 11:10:40 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04840 for ; Fri, 10 Sep 2004 11:10:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AAD9B91336; Fri, 10 Sep 2004 11:10:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 576F491332; Fri, 10 Sep 2004 11:10: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 C504A91333 for ; Fri, 10 Sep 2004 11:10:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A37C7848B3; Fri, 10 Sep 2004 11:10:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id C831D848C0 for ; Fri, 10 Sep 2004 11:10:26 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i8AFAIHC019151 for ; Fri, 10 Sep 2004 17:10:18 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Sep 2004 17:10:18 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Date: Fri, 10 Sep 2004 17:10:17 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB9064062C7@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Thread-Index: AcSWzWXFmiCIpfZkRTS0QKxWS1Y1yQAehUMg From: "STURA Marco Consultant" To: Cc: X-OriginalArrivalTime: 10 Sep 2004 15:10:18.0230 (UTC) FILETIME=[48754160:01C49748] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable You are right, we mistakenly used the code value 458 that was already proposed for another AVP. At the end I guess IANA will fix this while allocating the AVP codes, in the mean while I would use as proposed code value 261, if no one object. Regards Marco -----Original Message----- From: Joseph Harvell [mailto:jharvell@dogpad.net]=20 Sent: Friday, September 10, 2004 2:30 AM To: aaa-wg@merit.edu Cc: harvell@nortelnetworks.com Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict DCC draft 6 proposes AVP Code value 458 for both User-Equipment-Info and Service-Context-Id AVPs. I am implementing the encoding of Service-Context-Id. Does someone have an idea which AVP code will likely be assigned for Service-Context-Id? From owner-aaa-wg@merit.edu Fri Sep 10 12:25:17 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10682 for ; Fri, 10 Sep 2004 12:25:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFF0891339; Fri, 10 Sep 2004 12:25:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96DBB91338; Fri, 10 Sep 2004 12:25: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 2607591339 for ; Fri, 10 Sep 2004 12:25:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 11A1C84848; Fri, 10 Sep 2004 12:25:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 9A92B848F7 for ; Fri, 10 Sep 2004 12:25:03 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i8AGP1pE007232 for ; Fri, 10 Sep 2004 11:25:01 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Sep 2004 18:25:00 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550536AC73@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: STURA Marco Consultant , harvell@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Date: Fri, 10 Sep 2004 18:24:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk The authors better put this on their list of things to check during AUTH48 review (as issued by RFC-Editor just before publication) Bert > -----Original Message----- > From: STURA Marco Consultant > [mailto:Marco.STURA@consultant.vodafoneomnitel.it] > Sent: Friday, September 10, 2004 17:10 > To: harvell@nortelnetworks.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id > conflict > > > You are right, we mistakenly used the code value 458 that was already > proposed for another AVP. At the end I guess IANA will fix this while > allocating the AVP codes, in the mean while I would use as > proposed code > value 261, if no one object. > > Regards > Marco > > -----Original Message----- > From: Joseph Harvell [mailto:jharvell@dogpad.net] > Sent: Friday, September 10, 2004 2:30 AM > To: aaa-wg@merit.edu > Cc: harvell@nortelnetworks.com > Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict > > DCC draft 6 proposes AVP Code value 458 for both > User-Equipment-Info and > Service-Context-Id AVPs. I am implementing the encoding of > Service-Context-Id. Does someone have an idea which AVP code will > likely be assigned for Service-Context-Id? > > From owner-aaa-wg@merit.edu Fri Sep 10 12:50:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12538 for ; Fri, 10 Sep 2004 12:50:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0939D9133A; Fri, 10 Sep 2004 12:50:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C65989133B; Fri, 10 Sep 2004 12:50: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 36F849133A for ; Fri, 10 Sep 2004 12:50:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 252EB848A9; Fri, 10 Sep 2004 12:50:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 829D68480C for ; Fri, 10 Sep 2004 12:50:14 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8AGo6u03521 for ; Fri, 10 Sep 2004 12:50:07 -0400 (EDT) Received: from [47.102.209.53] (harvell-3.us.nortel.com [47.102.209.53]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S4X2WY4T; Fri, 10 Sep 2004 12:50:07 -0400 Message-ID: <4141DA1E.9010109@nortelnetworks.com> Date: Fri, 10 Sep 2004 11:45:18 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell Organization: Nortel Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040704 Debian/1.5-3 StumbleUpon/1.89 X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC proposed value for Service-Context-Id conflict References: <95A9A19987C57D42AA1CF59368CD1CB9064062C7@OMIMEXO06.omnitel.it> In-Reply-To: <95A9A19987C57D42AA1CF59368CD1CB9064062C7@OMIMEXO06.omnitel.it> 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 261 is already assigned to Redirect-Host-Usage. How about 461? STURA Marco Consultant wrote: >You are right, we mistakenly used the code value 458 that was already >proposed for another AVP. At the end I guess IANA will fix this while >allocating the AVP codes, in the mean while I would use as proposed code >value 261, if no one object. > >Regards >Marco > >-----Original Message----- >From: Joseph Harvell [mailto:jharvell@dogpad.net] >Sent: Friday, September 10, 2004 2:30 AM >To: aaa-wg@merit.edu >Cc: harvell@nortelnetworks.com >Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict > >DCC draft 6 proposes AVP Code value 458 for both User-Equipment-Info and >Service-Context-Id AVPs. I am implementing the encoding of >Service-Context-Id. Does someone have an idea which AVP code will >likely be assigned for Service-Context-Id? > > > > > From owner-aaa-wg@merit.edu Fri Sep 10 12:54:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12707 for ; Fri, 10 Sep 2004 12:54:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B305A9133C; Fri, 10 Sep 2004 12:54:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A0049133B; Fri, 10 Sep 2004 12:54:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EAA339133C for ; Fri, 10 Sep 2004 12:53:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA887848F7; Fri, 10 Sep 2004 12:53:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id 945DB84900 for ; Fri, 10 Sep 2004 12:53:57 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i8AGruHC012569 for ; Fri, 10 Sep 2004 18:53:56 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Sep 2004 18:53:55 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Date: Fri, 10 Sep 2004 18:53:55 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906F2CC4E@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Thread-Index: AcSXVCmYa9cumms6Tu63XdlKwJJV2AAAojBQ From: "STURA Marco Consultant" To: "Wang, Yile Enoch (Enoch)" Cc: X-OriginalArrivalTime: 10 Sep 2004 16:53:55.0381 (UTC) FILETIME=[C22B3650:01C49756] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable right! -----Original Message----- From: Wang, Yile Enoch (Enoch) [mailto:ewang@lucent.com]=20 Sent: Friday, September 10, 2004 6:35 PM To: STURA Marco Consultant Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Marco, I bet you meant 461, right? Thanks, Enoch -----Original Message----- From: STURA Marco Consultant [mailto:Marco.STURA@consultant.vodafoneomnitel.it]=20 Sent: Friday, September 10, 2004 11:10 AM To: harvell@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict You are right, we mistakenly used the code value 458 that was already proposed for another AVP. At the end I guess IANA will fix this while allocating the AVP codes, in the mean while I would use as proposed code value 261, if no one object. Regards Marco -----Original Message----- From: Joseph Harvell [mailto:jharvell@dogpad.net]=20 Sent: Friday, September 10, 2004 2:30 AM To: aaa-wg@merit.edu Cc: harvell@nortelnetworks.com Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict DCC draft 6 proposes AVP Code value 458 for both User-Equipment-Info and Service-Context-Id AVPs. I am implementing the encoding of Service-Context-Id. Does someone have an idea which AVP code will likely be assigned for Service-Context-Id? From owner-aaa-wg@merit.edu Fri Sep 10 12:55:45 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12835 for ; Fri, 10 Sep 2004 12:55:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02D389133D; Fri, 10 Sep 2004 12:55:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1EF59133F; Fri, 10 Sep 2004 12:55: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 592F99133D for ; Fri, 10 Sep 2004 12:55:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47AA6848F7; Fri, 10 Sep 2004 12:55:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis837.omnitel.it (mailout-2.omnitel.it [194.20.71.226]) by segue.merit.edu (Postfix) with ESMTP id 6EED784821 for ; Fri, 10 Sep 2004 12:55:20 -0400 (EDT) Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i8AGtJHC012909 for ; Fri, 10 Sep 2004 18:55:19 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Sep 2004 18:55:19 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Date: Fri, 10 Sep 2004 18:55:19 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906F2CC4F@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Thread-Index: AcSXUruX5kFJcalETyWs1gvsqChPoQABBdRA From: "STURA Marco Consultant" To: "Wijnen, Bert (Bert)" Cc: , X-OriginalArrivalTime: 10 Sep 2004 16:55:19.0167 (UTC) FILETIME=[F41BF0F0:01C49756] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Thank you Bert, we'll do it. Marco -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Friday, September 10, 2004 6:25 PM To: STURA Marco Consultant; harvell@nortelnetworks.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict The authors better put this on their list of things to check during AUTH48 review (as issued by RFC-Editor just before publication) Bert > -----Original Message----- > From: STURA Marco Consultant > [mailto:Marco.STURA@consultant.vodafoneomnitel.it] > Sent: Friday, September 10, 2004 17:10 > To: harvell@nortelnetworks.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id > conflict >=20 >=20 > You are right, we mistakenly used the code value 458 that was already > proposed for another AVP. At the end I guess IANA will fix this while > allocating the AVP codes, in the mean while I would use as=20 > proposed code > value 261, if no one object. >=20 > Regards > Marco >=20 > -----Original Message----- > From: Joseph Harvell [mailto:jharvell@dogpad.net]=20 > Sent: Friday, September 10, 2004 2:30 AM > To: aaa-wg@merit.edu > Cc: harvell@nortelnetworks.com > Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict >=20 > DCC draft 6 proposes AVP Code value 458 for both=20 > User-Equipment-Info and > Service-Context-Id AVPs. I am implementing the encoding of > Service-Context-Id. Does someone have an idea which AVP code will > likely be assigned for Service-Context-Id? >=20 >=20 From owner-aaa-wg@merit.edu Fri Sep 10 13:47:35 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16854 for ; Fri, 10 Sep 2004 13:47:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B0C091343; Fri, 10 Sep 2004 13:46:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 288D191348; Fri, 10 Sep 2004 13:46: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 A7AE491343 for ; Fri, 10 Sep 2004 13:46:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81D10847F7; Fri, 10 Sep 2004 13:46:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fmis437.omnitel.it (mailout-1.omnitel.it [194.20.77.121]) by segue.merit.edu (Postfix) with ESMTP id C5C9C8479C for ; Fri, 10 Sep 2004 13:46:11 -0400 (EDT) Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id i8AHkAx1028434 for ; Fri, 10 Sep 2004 19:46:10 +0200 (MET DST) Received: from omimexo06.omnitel.it ([10.21.12.196]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Sep 2004 19:46:09 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Date: Fri, 10 Sep 2004 19:46:09 +0200 Message-ID: <95A9A19987C57D42AA1CF59368CD1CB906F2CC51@OMIMEXO06.omnitel.it> Thread-Topic: [AAA-WG]: DCC proposed value for Service-Context-Id conflict Thread-Index: AcSXWnSfJSgoN2qDTfW2bI6eqDX6JQAA322Q From: "STURA Marco Consultant" To: "Joe Harvell" , X-OriginalArrivalTime: 10 Sep 2004 17:46:09.0912 (UTC) FILETIME=[0E7EAF80:01C4975E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, I meant 461 as I mentioned in another e-mail. Marco -----Original Message----- From: Joe Harvell [mailto:harvell@nortelnetworks.com]=20 Sent: Friday, September 10, 2004 6:45 PM To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: DCC proposed value for Service-Context-Id conflict 261 is already assigned to Redirect-Host-Usage. How about 461? STURA Marco Consultant wrote: >You are right, we mistakenly used the code value 458 that was already >proposed for another AVP. At the end I guess IANA will fix this while >allocating the AVP codes, in the mean while I would use as proposed code >value 261, if no one object. > >Regards >Marco > >-----Original Message----- >From: Joseph Harvell [mailto:jharvell@dogpad.net]=20 >Sent: Friday, September 10, 2004 2:30 AM >To: aaa-wg@merit.edu >Cc: harvell@nortelnetworks.com >Subject: [AAA-WG]: DCC proposed value for Service-Context-Id conflict > >DCC draft 6 proposes AVP Code value 458 for both User-Equipment-Info and >Service-Context-Id AVPs. I am implementing the encoding of >Service-Context-Id. Does someone have an idea which AVP code will >likely be assigned for Service-Context-Id? > > > > =20 > From owner-aaa-wg@merit.edu Fri Sep 10 18:28:30 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16116 for ; Fri, 10 Sep 2004 18:28:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70BE69121E; Fri, 10 Sep 2004 18:28:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2614D9121A; Fri, 10 Sep 2004 18:28: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 7331E9121E for ; Fri, 10 Sep 2004 18:28:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5BE32849CA; Fri, 10 Sep 2004 18:28:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from picanmix.dev.day.com (bsl-rtr.day.com [212.249.34.130]) by segue.merit.edu (Postfix) with ESMTP id 8165D84991 for ; Fri, 10 Sep 2004 18:28:15 -0400 (EDT) Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id i8AMS9e01753; Sat, 11 Sep 2004 00:28:10 +0200 (MEST) Received: from [10.2.8.57] ([10.2.8.57]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2004091100280812:33538 ; Sat, 11 Sep 2004 00:28:08 +0200 Mime-Version: 1.0 (Apple Message framework v619) Message-Id: Cc: uri@w3.org From: "Roy T. Fielding" Subject: [AAA-WG]: Re: AAA URI draft Date: Fri, 10 Sep 2004 15:28:07 -0700 To: aaa-wg@merit.edu X-Mailer: Apple Mail (2.619) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/11/2004 12:28:08 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 09/11/2004 12:28:09 AM, Serialize complete at 09/11/2004 12:28:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here are my comments regarding the AAA URI draft http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt update to RFC 3588. Sorry for the late review. The basic premise of this update, namely RFC 3588 [RFC3588] describes the Diameter base protocol for authentication, authorization and accounting purposes. The RFC provides for the existence of a DiameterURI AVP that contains a "aaa" or "aaas" URI. That definition of the "aaa" and "aaas" URI schemes follows the so-called hierarchical model specified in RFC 2396 [RFC2396], although aaa/aaas resources do not point to hierarchical resources. appears to be incorrect. For one thing, use of a namespace delegation mechanism like DNS within the scheme is inherently hierarchical in nature and benefits from using the common syntax forms. Furthermore, if Diameter is actually a deployed protocol, an arbitrary change in syntax to an existing scheme would significantly impact interoperability. What is more problematic, however, is that the "aaa" and "aaas" schemes seem to have been defined without a clear indication of what is being identified: RFC 3588 [RFC3588] does not provide semantics for the "aaas" URI nor it provide instructions to IANA to register any of those URI schemes in the official IANA registry of URI schemes. Unfortunately, the new draft doesn't really define what kind of resources are being identified either. It only says Both the "aaa" and the "aaas" URI schemes are used to identify resources related to authentication, authorization and accounting (AAA) functions that are accessed with AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]. but as near as I can tell, the only resources ever provided by those protocols are the service points (i.e., the fact that there is an AAA listener at that address). Why, then, is there a desire for a grab-bag identification scheme like "aaa", which hides the most important bits of information at the end of the URI, when the same thing can be better accomplished by specific URI schemes for each service? In other words, what I would propose is the following: d = "diameter" "://" authority ; Diameter/sctp d-tcp = "diameter.tcp" "://" authority ; Diameter/tcp d-tls = "diameter.tls" "://" authority ; Diameter/tls/sctp dtc = "diameter.tls.tcp" "://" authority ; Diameter/tls/tcp r = "radius" "://" authority ; RADIUS/udp t = "tacacs" "://" authority ; TACACS+/sctp t-udp = "tacacs.udp" "://" authority ; TACACS+/udp Note that the above removes all of the complexity described in section 3 regarding the various combinations of AAA protocol, transport, and session-based security that are not allowed. If you simply define the URI schemes such that illegitimate combinations aren't even an option, then you don't have to require that applications keep track of what combination of parameters are allowed. Likewise, all of the aliases (multiple URIs for the same service) are removed by specifying that the short scheme defines the most common protocol case (just as the "http" scheme defines HTTP over TCP, not HTTP over any transport). Furthermore, if we later discover that there are more resources hidden within the Diameter, TACACS+, and RADIUS servers beyond the mere existence of the service points, then all we need to do is add a path to the URI definition and those new services can be used by other information systems beyond AAA. A FAQ about URI scheme definitions is why doesn't the port component in authority come with parameterization, similar to that described in the draft for the aaa and aaas schemes? The reason is because applications use URI schemes as a hook by which to select modular handlers for the processing of requests. Therefore, placing that distinction in the scheme allows handlers for different transports to be developed and deployed independently. In contrast, embedding access parameters within a URI forces the application to choose either a generic handler that may be incapable of handling the URI, or to hard-code inspection of the URI path prior to URI handling (effectively breaking the orthogonality principle that is the central point of URI design). Cheers, Roy T. Fielding Chief Scientist, Day Software From owner-aaa-wg@merit.edu Fri Sep 17 05:53:00 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20377 for ; Fri, 17 Sep 2004 05:53:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 179FB9127A; Fri, 17 Sep 2004 05:51:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF54091245; Fri, 17 Sep 2004 05:51: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 12AB69127A for ; Fri, 17 Sep 2004 05:51:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2B1184B95; Fri, 17 Sep 2004 05:51:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 37D6D84B6E for ; Fri, 17 Sep 2004 05:51:30 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8H9pGT16414; Fri, 17 Sep 2004 12:51:17 +0300 (EET DST) X-Scanned: Fri, 17 Sep 2004 12:51:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i8H9p4C7028482; Fri, 17 Sep 2004 12:51:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 003B3Vwz; Fri, 17 Sep 2004 12:51:03 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8H9otY17851; Fri, 17 Sep 2004 12:50:55 +0300 (EET DST) Received: from [172.21.42.160] ([172.21.42.160]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 17 Sep 2004 12:50:45 +0300 Message-ID: <414AB375.2050200@nokia.com> Date: Fri, 17 Sep 2004 12:50:45 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "Roy T. Fielding" Cc: aaa-wg@merit.edu, uri@w3.org Subject: Re: [AAA-WG]: Re: AAA URI draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2004 09:50:45.0709 (UTC) FILETIME=[CDA2F7D0:01C49C9B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Roy: Thanks a lot for the comments. I have been waiting to see other responses from the AAA community, but unfortunately people seem to be busy with other stuff. Now, inline answers. Roy T. Fielding wrote: > Here are my comments regarding the AAA URI draft > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt > > update to RFC 3588. Sorry for the late review. > > The basic premise of this update, namely > > RFC 3588 [RFC3588] describes the Diameter base protocol for > authentication, authorization and accounting purposes. The RFC > provides for the existence of a DiameterURI AVP that contains a "aaa" > or "aaas" URI. That definition of the "aaa" and "aaas" URI schemes > follows the so-called hierarchical model specified in RFC 2396 > [RFC2396], although aaa/aaas resources do not point to hierarchical > resources. > > appears to be incorrect. For one thing, use of a namespace delegation > mechanism like DNS within the scheme is inherently hierarchical in > nature and benefits from using the common syntax forms. Agree with that. We meant the hierarchy of the URI, typically associated with a file system. In AAA resources, we are interested in find out AAA nodes, rather than a some other resource in a node (like a particular file in a file system). > Furthermore, > if Diameter is actually a deployed protocol, an arbitrary change in > syntax to an existing scheme would significantly impact interoperability. It is not. RFC 3588 is quite new. I am not aware of any deployments of RFC 3588. So an update by this draft will not suffer compatibility problems. > > What is more problematic, however, is that the "aaa" and "aaas" > schemes seem to have been defined without a clear indication of > what is being identified: > > RFC 3588 [RFC3588] does not provide semantics for the > "aaas" URI nor it provide instructions to IANA to register any of > those URI schemes in the official IANA registry of URI schemes. That can be easily solved by indicating that "aaa" and "aaas" resources identify AAA nodes running some AAA protocol (e.g., diameter, RADIUS, etc.) > > Unfortunately, the new draft doesn't really define what kind of > resources are being identified either. It only says > > Both the "aaa" and the "aaas" URI schemes are used to identify > resources related to authentication, authorization and accounting > (AAA) functions that are accessed with AAA protocols such as RADIUS > [RFC2865] or Diameter [RFC3588]. > > but as near as I can tell, the only resources ever provided by those > protocols are the service points (i.e., the fact that there is an AAA > listener at that address). Correct. > Why, then, is there a desire for a grab-bag > identification scheme like "aaa", which hides the most important bits > of information at the end of the URI, when the same thing can be > better accomplished by specific URI schemes for each service? Good question, for which I don't have an answer. Unfortunately I didn't participate in the definition of the AAA URI. The only thing I can tell you is that today there are other URI schemes that does not define the service (e.g., im:, pres: URIs are protocol agnostic). > In other words, what I would propose is the following: > > d = "diameter" "://" authority ; Diameter/sctp > d-tcp = "diameter.tcp" "://" authority ; Diameter/tcp > d-tls = "diameter.tls" "://" authority ; Diameter/tls/sctp > dtc = "diameter.tls.tcp" "://" authority ; Diameter/tls/tcp > > r = "radius" "://" authority ; RADIUS/udp > > t = "tacacs" "://" authority ; TACACS+/sctp > t-udp = "tacacs.udp" "://" authority ; TACACS+/udp > I don't mind keeping the "diameter:", "radius:" and "tacacs:" URIs. they can be interesting to define them. But I don't think the idea of linking the transport protocol to the URI scheme is a good argument. As far as I know, the IESG has already shut down this kind of initiatives in the past. Additionally, other URI schemes like the SIP URI (RFC 3261) went already through this process, and end up defining "sip" and "sips", the former allowing TCP, UDP and SCTP as transport protocols, the latter indicating TLS over TCP. Further more, I don't think radius and tacacs use URIs (as for today), so perhaps we might need only the "diameter:" and "diameters:" URIs. The other point that you raised here is related to the double slash. Note that I don't even think the double slash is needed to identify the kind of resources we are identifying, at least this is what I understand when I read section 2.1.2 of RFC 2718: 2.1.2 Improper use of "//" following ":" Contrary to some examples set in past years, the use of double slashes as the first component of the of a URL is not simply an artistic indicator that what follows is a URL: Double slashes are used ONLY when the syntax of the URL's contains a hierarchical structure as described in RFC 2396. In URLs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes which do not contain a conformant hierarchical structure in their should not use double slashes following the ":" string. > Note that the above removes all of the complexity described in > section 3 regarding the various combinations of AAA protocol, > transport, and session-based security that are not allowed. If you > simply define the URI schemes such that illegitimate combinations > aren't even an option, then you don't have to require that > applications keep track of what combination of parameters > are allowed. Likewise, all of the aliases (multiple URIs for the > same service) are removed by specifying that the short scheme > defines the most common protocol case (just as the "http" scheme > defines HTTP over TCP, not HTTP over any transport). On the contrary I would argue that existing URI schemes today share the scheme with different transport protocols. For instance the sip URI (RFC 3261) allows TCP, UDP and SCTP transports, whereas the sips URI means TLS over TCP. I believe this is the model supported by the IESG (otherwise, I don't understand how all the RFCs that follow the SIP model have been approved). > > Furthermore, if we later discover that there are more resources > hidden within the Diameter, TACACS+, and RADIUS servers beyond > the mere existence of the service points, then all we need to > do is add a path to the URI definition and those new services > can be used by other information systems beyond AAA. Note the case, even in a foreseeable future. > > A FAQ about URI scheme definitions is why doesn't the port component > in authority come with parameterization, similar to that described > in the draft for the aaa and aaas schemes? The reason is because > applications use URI schemes as a hook by which to select modular > handlers for the processing of requests. Therefore, placing that > distinction in the scheme allows handlers for different transports > to be developed and deployed independently. In contrast, embedding > access parameters within a URI forces the application to choose > either a generic handler that may be incapable of handling the URI, > or to hard-code inspection of the URI path prior to URI handling > (effectively breaking the orthogonality principle that is the > central point of URI design). > The design of those handlers has not been a problem for protocols like SIP. So I don't quite agree with your argument that there seems to be an implementation problem. It seems that such problem has been solved, and it seems there are no requirements in this respect. > > Cheers, > > Roy T. Fielding > Chief Scientist, Day Software > > Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon Sep 20 05:18:56 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13228 for ; Mon, 20 Sep 2004 05:18:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE8D39120C; Mon, 20 Sep 2004 05:17:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8348912C7; Mon, 20 Sep 2004 05:17: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 96C009120C for ; Mon, 20 Sep 2004 05:16:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7887084CC5; Mon, 20 Sep 2004 05:16:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by segue.merit.edu (Postfix) with ESMTP id 9BDC484CF3 for ; Mon, 20 Sep 2004 05:16:49 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i8K9Gm5S011598 for ; Mon, 20 Sep 2004 11:16:48 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i8K9GmuC021918 for ; Mon, 20 Sep 2004 11:16:48 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Sep 2004 11:16:48 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468674C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Client side initiated session termination for Diameter base proto col Date: Mon, 20 Sep 2004 11:16:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all, Section 8.4 of RFC 3588 states: " When a user session that required Diameter authorization terminates, the access device that provided the service MUST issue a Session- Termination-Request (STR) message to the Diameter server that authorized the service, to notify it that the session is no longer active. An STR MUST be issued when a user session terminates for any reason, including user logoff, expiration of Session-Timeout, administrative action, termination upon receipt of an Abort-Session- Request (see below), orderly shutdown of the access device, etc. " I could not find a "user logoff" event in the CLIENT, STATEFUL state machine in Section 8.1? Ciao Hannes From owner-aaa-wg@merit.edu Tue Sep 21 15:47:58 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14793 for ; Tue, 21 Sep 2004 15:47:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED5369125E; Tue, 21 Sep 2004 15:46:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6CEE9122D; Tue, 21 Sep 2004 15:46: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 734519125E for ; Tue, 21 Sep 2004 15:46:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2161A849A6; Tue, 21 Sep 2004 15:46:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (c-67-182-139-247.client.comcast.net [67.182.139.247]) by segue.merit.edu (Postfix) with ESMTP id 773FC847F7 for ; Tue, 21 Sep 2004 15:46:54 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i8LJcLQ21513 for ; Tue, 21 Sep 2004 12:38:27 -0700 Date: Tue, 21 Sep 2004 12:38:21 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Back online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Just a message to say that my mail server is back online now. My ADSL link went down and so I had to move the server to another link (it's now on a cable Internet link). If you had sent any mail to me in the last two weeks and didn't get a response, please resend. From announcement@computeradmin.org Fri Sep 24 05:11:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22872; Fri, 24 Sep 2004 05:11:24 -0400 (EDT) Received: from c-66-41-71-165.mn.client2.attbi.com ([66.41.71.165]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CAmDs-0005oB-B1; Fri, 24 Sep 2004 05:18:38 -0400 Received: from ef0.oyp7t.com [110.43.91.37] by c-66-41-71-165.mn.client2.attbi.com with ESMTP id 89914702 for ; Fri, 24 Sep 2004 04:07:56 -0600 Message-ID: <7$0vllr0$--0--ee3h-716$2-$w5$-i@2y1v5g> From: "Admin" To: iporpr-admin@ietf.org Subject: ADV: Announcement To All Staff Date: Fri, 24 Sep 04 04:07:56 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E...A7CBBDE8D94.ED_C" X-Spam-Score: 18.0 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. --E...A7CBBDE8D94.ED_C Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Monday, September 27, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Monday, September 27, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Monday, September 27, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Monday, September 27, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Monday, September 27, 2004= Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp Avtech Direct 22647 Ventura Blvd., Suite 374 Woodland Hills, CA 91364 --E...A7CBBDE8D94.ED_C--